Re: One more item to the collection of Lua hate-speech

[Mark Hamburg <mark@...>]

On Jul 4, 2010, at 8:48 AM, Mark Hamburg wrote:

> On Jul 4, 2010, at 12:13 AM, Wim Couwenberg wrote:
> 
>> Globals could be deprecated if Lua would support some form of "import"
>> construction natively.  For example "import os" would declare "os" to
>> refer to a package where it is in scope.  Many programmers are already
>> used to such things (packages, namespaces, ...) so less to explain.
>> ;-)  And probably "constant" package references such as os.print could
>> compile into array indexing so it would be very fast.  (The - growing
>> - set of such references into any package is known at compile time.)
>> At least to me something like this would feel as a natural next step
>> in the development of Lua.
> 
> I'm all for this for most development work. I've always liked the simplicity of the Oberon module system.
> 
> That said, globals do end up having their place in interactive development, but perhaps there are reasonable ways to work around that.

Eliminating globals. A speculation (as opposed to a proposal).

* Add an import statement that basically does a require and creates a local variable. Or just make require a pre-populated value supplied as a parameter to the chunk loader. (See object-capability model.) In fact, we could supply a table full of values to the chunk loader that would provide a set of pre-bound locals.

* All otherwise undeclared names become chunk level locals effectively defined at the beginning of the chunk.

* Insert vigorous hand waving here: Provide a way to compile an extension to a chunk as a way to support interactive mode.

Note that this doesn't really get rid of globals. It just pushes them down to the chunk level and thereby allows the use of upvalues for references and eliminates cross-chunk interference. I'm not sure I can come with an argument for the change, but it does stake out sort of a middle-ground on things.

Certainly it isn't high on my list of priorities which on this general subject would focus more on shifting require/module away from modifying the global scope and on providing better hooks for compile-time semantic analysis -- e.g., provide a way to run a global reference through a validation function at compile time rather than trying to simulate the effect with a byte-code analysis. (A separate validation analyzer would also work. It's just that it seems likely to share a fair amount with the compiler.)

Mark