Re: os.setenv()???

[Rici Lake <lua@...>]

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.