lua-users home
lua-l archive

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

David,

Environment variables bother me tremendously. They have the potential to change the meaning of almost everything in a piece of code without much visibility as to what that change is, and I am unwilling to deal with that level of hidden variability.  The only things that should be unprefixed in code or in a module are the primitives of the language and the local variables. Globals are unneeded. Variables can be explicitly exported and then used by any code that explicitly imports them. Then, you don't have to worry about scope when the order of code is changed ( a calling b instead of b calling a). _G should be no more privileged than any other reference. Unless it is explicitly referred to, it should not be accessible. I might want to use an entirely different print() in one module than in another or more than one print() in a single piece of code, and print() functions, like regex implementations, are separate languages in themselves. If I explicitly import them, and prefix them based on that explicit importation, then, again, no one will ever have to wonder about masking or globals of any kind. Now, the language should probably support an agreed library of external functions, just to make implementation without reinvention possible, but that agreed on library should not become a limitation to the language nor variously implied or changed environments a danger to every piece of code.

This argument is very similar to the one about exact math as opposed to math limited by the hardware instructions available to a language. Certainly, the semantics of a language as used by a compiler or interpreter should use exact math, or state exactly the limitations imposed. But in the actual math performed by programs, there should be two distinct forms of math, one exact, with defined calculation and rounding, and one using hardware fairly directly, such as floating point hardware. Without the greatest of care, floating point hardware can produce some really strange anomalies, and integer math is always subject to limitations. The point is that when a is added to b, you should always get the correct, exact result, or an error, but not a wrap or an untracked overflow. Libraries exist that do exact math at any arbitrary number of significant digits. The point is that code should be as unambiguous as possible, with the fewest number of hidden limitations.

Everett L.(Rett) Williams II



David Manura wrote: 
On Sun, Aug 8, 2010 at 2:57 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
  
Anyway, isn't this a continuation of the "referencing table elements
within the same table constructor" thread?
    
The gist of that seemed to be to allow

  return {x = 2; y = function() print(x) end}

where print resolves to _G and x resolves to the table, which also
could be possible to resolve at compile time.  So, it is related.