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

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

On Sunday, March 30, 2014, Tim Hill <drtimhill@gmail.com> wrote:
> On Mar 30, 2014, at 11:36 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> >
> > 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`.
> >
> > The Lua way is to provide methods, not policies. This proposal
> > involves policy, not method. I do not support it.
> >
>
>
> I disagree with this as a definition of “the Lua way"; if it were then 5.3 would certainly NOT include bitwise operators and we’d just have a bit64 library. Second, a blanket “all policy is bad” argument is rather dubious. SOME policy is both necessary and good; that’s why Lua specifies the precision of floats and (in 5.3) the width of integers (never mind about the compile-time variants).
>
> To my mind “the Lua way” is have as LITTLE policy as is practical. The question, therefore, is really this: is it sufficiently useful to have a policy-based method to manage global variable declaration to justify it’s addition? Notice that this has nothing to do with HOW such a policy is realized. This is because policies solve issues of standardization, while the realization of policies involve issues of efficiency and compatibility (and, dare i say it, elegance).
>
> The OP points out that the problem with existing implementations/work-arounds/hacks (choose your word) is that they all collide with 3rd party code such as libraries. I’ve had this issue as well; it doesn’t really matter what you do with the existing solutions, they only really work if you have total control of 100% of the source in your project.
>
> And, to be blunt, it *is* a wretched nuisance when you spend an hour staring at code that should work only to notice a simple single-letter typo in a variable name was the cause.
>
> I personally don’t agree with the OP’s proposed solution; it feels odd to me. But I *do* agree with the motivation to try to create such a solution.
>
> —Tim

Frankly, it's a classic mistake to propose a solution anyway, and so I'll retract it and agree with Tim. I suckered myself into that by considering past arguments against it that highlighted Lua's use as as configuration file. 

Variable assignment is something that the language provides. Changing globals to require explicit declaration (intentional?) is a language feature that can be implemented to decent effect as a library, but it's different.[1]

Just as extending the type system or adding features to automate certain OOP features found in other languages could be done as a library, it's generally not something that can survive use beyond your own application code. 

My point is not that my imementation idea is a great way to go or deserves defending. It's that a built-in mechanism to require explicit global declaration would make Lua better, at least when people are using it for more than a configuration file format.

-Andrew

[1] as a module, you either need to remove it or have it as a dependency. You can have it preloaded as part of your dev env, but then when you switch computers (as I do) you need to bring it along. This still doesn't cover cases where you reset _ENV. My proposal is probably not enough better in this regard.