lua-users home
lua-l archive

Re: os.setenv()???

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

Rici wrote: 
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.

Certainly there are two different paradigms. I just think that a thin API offers more power and performance, and allows the community to develop simpler interfaces on top of the standard. And though you say a high-level abstraction is simpler, I rather use the functions I already am familiar with than learn a Lua-specific abstraction that does the same thing.

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:

Is it easier to check that a given function is implemented in the current environment when the function is a high-level abstraction? Is checking for std.putenv (a thin interface) harder than checking for os.setenv (your abstraction)? I don't see that it is, but maybe a thin interface would introduce more checks than necessary, defeating the performance boost gained from a simpler translation. I dunno.

I guess the current consensus though is that a standard should define a set of functions that may or may not be implemented on a given system, and these functions can be high-level abstractions of their actual implementations for simplicity reasons. If Lua goes in this direction, then perhaps loadlib and friends should be moved to this new library, so that any function in the standard libraries (besides the new one) is guaranteed to be implemented in the current environment, and functions in the new library should always be checked before calling. A clean divide like this would make me happy; I just wouldn't use the new library and be guaranteed my script runs everywhere.


On Sun, 2006年01月08日 at 14:04 -0500, Rici Lake wrote: 
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.

AltStyle によって変換されたページ (->オリジナル) /