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

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

On Sunday, March 30, 2014, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> 2014-03-30 19:57 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
>
> > Because `strict` is not part of the standard library, it is not as
> > conveniently at hand. Therefore, people reinvent it or don't include
> > it and, as a result, it's not part of the language's "culture."
>
> True. But not necessarily bad.
>
> I am currently working on a program I am revising to take
> advantage of 5.3 (utf8 and no `=` needed). It contains:
>
> local globals = {}
> setmetatable(_ENV,{
> __index=function(tbl, key)
>    local val=rawget(tbl,key)
>    if val then return val end
>    val = globals[key]
>    if val then return val end
>    if key:match("%u%l") then return guess(key)
>    end
> end;
> __newindex=globals})
>
> The reason I mention this is because the trick is the same
> one that strict.lua uses. I suppose this counts are reinventing
> it, but I adapt it to a somewhat different purpose.
>
> > That is, it can't become a "best practice" to enable it or include it and
> > it can't be considered properly in modules that people may write. It's
> > not a bug if they create globals, necessarily, and you can't expect
> > someone else to `rawset(_ENV, x, 1)` when the do.
>
> Which IMHO is a good thing.
>
> > ##Proposal
> >
> > My idea (probably not a new one) is in two parts:
> >
> > 1: `global` keyword is (probably) shorthand for rawset(_ENV, var, val)
>
> The effect of this proposal can be achieved easily. The syntax is only
> slightly different: `global {var1=val1; var2=val2}` instead of
> `global var1,var2=val1,val2`.

My example and yours wouldn't provide a direct replacement. 

global {var = nil} would fail to allow someone to predefined a variable as nil. If you augmented it to support `global {"var"} then it could be made to predefined variables with nil values. 

 

> The Lua way is to provide methods, not policies. This proposal
> involves policy, not method. I do not support it.

I agree with that principle and still maintain my conclussion. There are reasons to permit many paths to objects or functional programming patterns. I can't see the upside here and a global keyword has an impact *on how people are likely to use the language.* I was careful to acknowledge the existence of alternatives, in order to highlight this (perceived) benefit. 

The effect could be achieved as a "default index and newindex" for _ENV,  much as string has a default index that may be replaced, and so your hack-ery could continue unabated. :)

-Andrew