Re: a case for multiple environments - expressing modules more naturally

[Everett L Williams II <rett@...>]

Shawn,

That certainly is cleaner, but any wrapper that operates inline and is not a permanent part of the code leaves itself vulnerable to being wrapped again and again, or having the wrapping lost or mismanaged in the update process, where the parts of the wrapper are far distant from each other. That is the type of "magic" that bothers me. The problem with environments and inline namespaces is that they are so all-inclusive. So much can be done that is unintended or just not part of what is trying to be accomplished at the moment. As code is expanded, the side effects are much more likely to become apparent. If the only external variables available are those that are explicitly shared from that external source, and that are explicitly brought into the present context, then those side effects are a lot less likely to happen, and if they do, the blame will be on the person who did not look at what they were referencing. It's the difference between swimming in the ocean and swimming in a private pool. In the ocean, I never can fully know what is swimming with me, while in a private pool, I always know. A module is a jar with a top, and everything should have to come in or go out from the jar through the top. Putting multiple modules into a single file is a mistake for that reason. Effectively, you have made the modules inline parts of a string of code, with all the felonies that can happen in that environment. Now, if there is some "make" process that puts all the modules and other pieces into a single file, that is indeed a different kettle of fish, because that single file is never to be directly edited.

That also brings up another piece of how that sharing process should work. Variables should be shared as read-only or read-write and that should create a property that can be interrogated. In other words, the sharing should be entirely in the control of the entity that shares. That would allow for the creation of commercial, black-box code at some point in all of this.

Everett L.(Rett) Williams II



Shawn Fox wrote:

On Tue, Aug 10, 2010 at 12:23 PM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

Currently we see _ENV more as a simple way to define how globals work
(and the dependency between a chunk and the global table) than as a
mechanism for module construction.

Nevertheless, I should mention that there are very few details of
how _ENV works:

- all chunks (the unit of 'loading' in Lua) are compiled as if they
were a function defined under a "local _ENV" declaration. (In 5.1,
all chunks are already compiled as if they were a function; the only
novelty is this upvalue _ENV.)

- all references to undeclared variables are syntactically translated to
_ENV.varname. ("syntactically" means that the compiler rewrites 'x' as
'_ENV.x' and follows from there.)

- when a chunk is loaded with 'load' and the like (loadstring, loadfile,
dofile, etc.), its external _ENV variable gets the value of the global
table. When a chunk is loaded with 'loadin', _ENV gets the value
given as argument.

-- Roberto

So based on this I think what I'm really asking for is that something like:

foo = namespace
    local x = 99
   function bar(y) print(x+y) end
end

would be the same as:

foo={}
loadin(foo, [[
    local x = 99
    function bar(y) print(x+y) end
]])

I have no idea how others feel about it, but to me this would be tremendously useful and simple to use.  What I'm really trying to do here is to be able to limit the scope of variables for a chunk of code without having to put the code in a separate file.