Re: os.setenv()???

[Rici Lake <lua@...>]

On 8-Jan-06, at 5:16 PM, Lisa Parratt wrote:

> Interpreted code will *always* be slower than native code. You can 
> have power (expose the primitives) or performance (wrap function call 
> sequences in single Lua functions), but I severely doubt you can have 
> both.

Very true. However, there is also another criterion, possibly more 
important: ease of use.

Many OS facilities are very similar between platforms, and in many 
cases the differences are more an artifact of the C interface than 
actual functionality (for example, whether "setenv" is called setenv or 
putenv or whatever; or the precise nature of the timespec structure). 
Obviously, this does not apply to *all* OS facilities (process 
management differs radically between platforms, as does the GUI 
framework if you consider that an OS facility) but certainly any OS 
which supports directories has some way to iterate the contents of a 
directory. (There might be more than one way, and an OS-specific 
interface would be necessary to provide access to alternatives, but 
there is at least one way which could be mapped onto a Lua iterator.)

Specifying optional Lua-like interfaces for common features makes 
everyone's life easier. First, it makes it easier to write code for 
different platforms (or for multiple platforms) because you can use the 
standard interfaces. Second, it makes it easier for implementers, since 
they don't have to think up a binding style. Finally, it makes it 
easier for documentors, which is to say for everyone, because the 
documentation only needs to be written once, and only really 
platform-specific stuff needs to be documented separately.

I'm not proposing standardizing every detail of OS interaction á la 
Posix; simply carefully specifying and documenting a set of useful 
interfaces which are commonly available on most platforms, as well as a 
simple means of discovering whether the given interface exists. (The 
simplest one would be having 'require' fail, I suppose, but there are a 
number of alternatives; it would be useful imho for the community to 
decide on one, bearing in mind the historical disaster of Posix's 
periodic changes to feature discovery mechanisms.)