Re: [proposal / postulation]: global keyword that works with lua as config file

[Andrew Starks <andrew.starks@...>]

On Mon, Mar 31, 2014 at 11:46 AM, David Favro <lua@meta-dynamic.com> wrote:
> On 03/30/2014 01:57 PM, Andrew Starks wrote:
>
>> `strict` is available and works well.
>
> I'm not sure I agree that it works well: it is problematic in that it
> doesn't support name scoping, by which I mean this will raise an error:
> require("strict");
> local foo = require("foo"); --< a global is set in the module definition
>
> As a user of module "foo", I have no way of knowing if it pollutes the
> global namespace or not, and I've found that some popular ones do.  If I
> require() all of my needed modules prior to require()ing "strict", I am
> still not safe:
>
> local foo = require("foo");
> require("strict");
> local bar = foo.bar(); --< global is set in this function
>
> Again, as a user of module "foo", I have no way of know if and when it will
> set a global, and once I require("strict") no module is usable that doesn't
> promise to never set a global as part of its "contract".
>
> It might be possible to try to load modules using their own private
> environments, which aren't strict-protected, but aside from being a PITA
> [require() has no environment parameter, I guess loadfile() would be
> needed], I suspect that this will introduce a lot of other problems.
>
> The same problem arises when creating modules, only inverted: if I
> require("strict") from within my module-definition (unless I take special
> precautions to put my module into its own environment), I am likely to break
> any code which require()s my module, if it ever sets a global -- so it's
> effectively verboten to do so from anywhere within a module, and (static
> analysis tools aside) it's difficult to detect subtle bugs in my module due
> to a forgotten 'local'.
>
> So, I suggest that any proposed innate strict-global feature should have
> some mechanism to (perhaps optionally) only be enforced for accesses to the
> global environment from the chunk in which it is specified; _STRICT as
> proposed does not respect this.  Thinking along these lines, what I think
> might be more useful than throwing runtime errors, and perhaps even easier
> to implement, is a mechanism to specify default-local rather than
> default-global for names declared _just_ within a particular chunk.  Either
> or both would be welcome.
>
> -- David
>
As you may be aware: default local has many problems and has been
discussed many times. My conclusion is that default local is just
"wrong" and the only "right" is explicit global and local, but in
Lua's case, the status quo is most appropriate. This is because Lua is
used as a configuration file format.

You didn't mention this in your post, so I'll ask you to frame globals
in the context of Dirk's post (and my followup): globals are just a
table and nothing more. Ignoring _ENV: what would you propose that
does not disrupt the way that tables work and does not complicate the
implementation of globals?

It's a sincere question, because I haven't ruled out  that there
*might* be a clever improvement, somewhere. If the requirements are to
not change the way that _ENV works (I wouldn't want that) then I'm not
sure if change is possible, without a wholesale change to the
language...

One could go the opposite way and, by default, demand "global", except
where a header line like "@implicit" was at the beginning. With global
or implicit, lua assigns the var_name and value to _ENV. Without it,
it errors...

That said, I now suspect that, in a dynamic language, analysis might
be a better approach. It's free, in that it doesn't need to go along
with your deliverable and checking for something always costs.

I'm easily lead. :)


-Andrew