On 8-Jan-06, at 1:21 PM, Ryanne Thomas Dolan wrote:
> Also, the standard interface should be absolutely as thin as possible.
In that case, we should ditch io.lines(), right? And abandon the
abstraction of various dynamic loading interfaces into loadlib()?
Lua is a lightweight language. There are a number of ways of
interpreting that; one is as you suggest, make the interfaces as thin
as possible. The other one is to make the interfaces as simple as
possible. I'd personally opt for the latter.
> Rather than providing a table as an abstraction of getenv and setenv
> (as Rici proposes), the standard interface should define a one-to-one
> mapping from Lua functions to C functions such as getenv, setenv,
> putenv, and ChangeEnvironmentVariableToString (or whatever C functions
> implement the desired task). If a function isn't provided by the
> current OS, then the function is left undefined in the environment.
That's another possible approach; leaving the function undefined is
also quite a reasonable approach. However, I don't see the point of the
following:
> local function resolve_setenv ()
> if std.setenv then
> return std.setenv;
> elseif std.putenv then
> return std.putenv;
> elsif std.ChangeEnvironmentVariableToString
> return std.ChangeEnvironmentVariableToString;
> else
> error ("std.setenv/putenv/ChangeEnvironmentVariableToString
> is not implemented in this environment");
> end;
> end;
If you have to include that in order to portably setenv, then it might
as well be part of the library implementation. If you prefer that the
signal of non-implementation be that the function not be defined, then
you can achieve the same effect with a simple:
os.setenv("key", "value")
which will throw an error if os.setenv is undefined. (Or you could
pretest.)
> Writing a standard library that morphs based on the OS is extremely
> hard or impossible to write.
In the case of GUIs, yes. In the case of setenv, no. :)
> The only common denominator is C 89, which Lua already implements
> decently.
There are others. APR, for example, provides a cross-platform
implementation of a large subset of Posix facilities; presumably, it
was not easy to write, but it exists (and with a liberal open source
licence).
> A one-to-one mapping is the only way to safely provide system
> dependent functionality to all platforms. Anything else will only be
> portable to a finite set of OS, which is not acceptable.
That seems like an odd statement to me. A one-to-one mapping provides
system-dependent functionality for the platform for which the mapping
is written. It is portable only by abstraction. Whether that
abstraction is done at the Lua level or in the context of a standard
library interface is simply a design option, but the use of the
language is certainly simpler if it is done through a standard library
interface. (Of course, the existence of the standard interface does not
actually mandate its use in a given project. You are certainly free to
implement alternative dynamic loading facilities, for example, which
could be a one-to-one mapping with, say, Netware NLMs. However, they're
not going to be as easy to integrate with the Lua 5.1 package
mechanism.)
> For example, if some OS provides ChangeEnvironmentVariableToNumber in
> addition to ...ToString, this functionality is not lost in the
> standard.
Not at all. The (hypothetical) standard says that setenv(string,
string) does something and returns true, or does nothing and returns
nil and an error message. It does not say what setenv(string, number)
does, although it would be nice if it obeyed the same general outline.
If a given OS provided ChangeEnvironmentVariableToRGBAColor, then the
standard provides a strong hint as to how to implement that. The result
would be a Lua environment which was predictable.
