lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 8-Jan-06, at 11:00 AM, Chris Marrin wrote:

This is all good discussion. But let me say that my original intent was to say that there are many capabilities that Lua has built in (file I/O, a few os functions). But this set is incomplete and therefore other libraries need to be brought in.

Leaving aside loadlib, the facilities Lua offers are essentially those guaranteed in standard C (89). So it's not an arbitrary choice, really.

However, I strongly agree with this:

The choice of libraries is many and often conflicting and I think this hurts Lua development.

Lua should not, in my opinion, include as standard libraries which require OS interfaces which may not exist on a conforming C implementation [Note 1]. However, there are many OS interfaces which are commonly available on popular platforms, and it would be nice if the Lua API for such interfaces were consistent. (For example, the name of the Lua function os.setenv should not depend on whether the underlying platform uses setenv, putenv, or ChangeEnvironmentVariableToString.)

So I (continue to) believe that an important step is to define (and achieve consensus on) the library APIs which should be used to bind such OS features. That way, we could at least know that if there were a way of setting environment variables, it would be called in the same way, say os.setenv(varname, value) where both varname and value are strings [Note 2]; and furthermore that os.setenv should not do something else. (In fact, in this particular case, it could be included in the standard distribution with a default implementation which returned nil; a particular os library could then replace that with an implementation that did change the environment variable and returned a true value.)

The case of loadlib() provides an example of how this model can work: it is an OS-specific facility, but the interface is well-defined in the language, and the default implementation simply returns an error indication.

There is always the temptation to create shallow wrappers around OS-dependent facilities, which mimic the low-level OS API. This is usually a mistake; it makes it harder to write cross-platform code, and it often results in APIs which are "un-Lua-like". As a case in point, a directory iterator is much more consistent with Lua style than would be a shallow wrapper around opendir(), readdir(), etc.


Note 1: In fact, it is possible that Lua already includes too much in the standard distribution. For example, embedding Lua often requires replacing I/O implementations.

It often comes as a surprise to embedders that print() and io.write() are unrelated, and that loadfile() cannot accept a file object returned by It would be worth thinking about how to make it possible to synchronize the implementations of I/O between the base library and the io library, so that, for example, when the io library is included, base library implementations are redefined to use it.

Note 2: Personally, I'm not convinced by the function call interface to getenv and setenv; it seems to me that it would be more natural to implement this directly as a table-like object which implements __index (by default) and __newindex (if that facility is available). This would allow the possibility of simulating setenv with an ordinary Lua table, in the case that the underlying platform does not provide any setenv capability.