[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: about lposix
- From: Luiz Henrique de Figueiredo <lhf@...>
- Date: Tue, 17 Oct 2006 11:21:21 -0300
Let me summarize the current state of afairs:
- The OS library included in the official Lua distribution is lacking many
important OS features because it is restricted to what ANSI C provides.
So, there is a clear need for better libraries to access OS services.
- Unfortunately, my lposix has lagged behind and several partial alternatives
have been implemented. This is duplicated effort that we should avoid.
- Providing a POSIX binding for Lua is a large task because POSIX is a huge
standard. Moreover, it is not clear whether providing a thin binding
(that is, too close to the POSIX API) is useful. A slightly higher-level
binding is probably best suited to Lua. In particular, combining several
services into one Lua function usually works best (for instance, there
is no need for setenv and unsetenv; setenv(name,nil) works fine as unsetenv.)
- The recent discussion brought an important point: we do not need a full
POSIX library; we need a simple abstraction for common OS services. The
"ex" API is one good example of that [1]. So is LuaFileSystem [2].
The point is not that it is difficult to bind POSIX to Lua; it is not.
The point is that we need cross-platform access to common OS services.
So, my suggestion, which has already been made recently, is that we join
efforts and write an extended OS library that works on POSIX and Windows,
and that can be easily ported to other OS. That requires that we reach
an agreement about what to include in it and most important what *not* to
include.
I can try to coordinate this by extracting the relevant parts of lposix and
the other libraries as needed. But I cannot do anything about Windows...
Or if someone else wants to takes this over, it's ok, but we'd still like to
discuss what shall be included and what shall not. We must avoid bloat.
Again, the point is that it is simple to include any given function, but
we have to consider the other requirements: natural Lua interface,
documentation, ease of porting, etc.
--lhf
[1] http://lua-users.org/wiki/ExtensionProposal
[2] http://www.keplerproject.org/luafilesystem/index.html