lua-users home
lua-l archive

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

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;
        error ("std.setenv/putenv/ChangeEnvironmentVariableToString is not implemented in this environment");

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.