Re: os.setenv()???

[Rici Lake <lua@...>]

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 io.open(). 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.