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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
Steve brought up Lua gotchas in a different context. I didn't have
"strict" loaded and had a long bout with a hidden bug, leading me wish
that strict global creation was a more integral part of Lua.

This has been a topic from the past. I bring it up now because of 5.3,
although I'd much prefer a release of 5.3 to be much sooner, as I
think it's a nicely sized release, as is.

##Motivation and Acknowledgement of Existing Alternatives:

`strict` is available and works well. Also, it doesn't slow much of
anything down because it's only activated when a global is explicitly
set to nil or when one is accessed without being set.

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." 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.

Second, using strict makes assigning globals somewhat awkward in that
an assignment is now a function call. This might be good or bad; good
if one considers globals to be something that should be made
difficult.

I think it's bad, because it might be motivation to not use strict or
to consider it a "hack."

Lua is very flexible and just about any language that isn't already
present can be created at run time, including this. I think a keyword
is warranted, because it is more likely to help people that would
otherwise not load it and it creates a standard way to do something
that would benefit from being standard.

##Proposal

My idea (probably not a new one) is in two parts:

1: `global` keyword is (probably) shorthand for rawset(_ENV, var, val)

2: _STRICT is a value that is global and defaults to `false` (or nil,
but one must be able to assign it globally).

Example
```lua
print(_STRICT)
--> false
x = 1
print(x)
--> 1
_STRICT = true
global y = 2
print(y)
--> 2
z = 3
--> error: Implicit assignment of global "z" attempted at line 3.
```

This way, "Lua as a config file" is not effected and there is now a
way to make globals explicit and to do it in a way that looks like
part of the language, while doing it.

I must acknowledge that this idea might not rise to the level of need,
or it may also not fit well within a microwave. :) I do think it would
improve Lua and the way that people use it.

Thanks!

-Andrew

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2014-03-30 19:57 GMT+02:00 Andrew Starks <[hidden email]>:

> 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`.

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

Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
In reply to this post by Andrew Starks
Am 30.03.2014 19:57 schröbte Andrew Starks:
>
> I think it's bad, because it might be motivation to not use strict or
> to consider it a "hack."

It *is* a hack. An impressive one because it achieves a lot with little
code, but on the other hand it modifies a shared resource, so it affects
other people's code, and prevents them from setting a metatable on `_G`
themselves (or at least makes it harder). And as you already mentioned,
there are a lot of alternatives (most of which I consider superior to
`strict.lua`), and this is my main motivation not to use `strict.lua` ...

>
> ##Proposal
>
> My idea (probably not a new one) is in two parts:
>
> 1: `global` keyword is (probably) shorthand for rawset(_ENV, var, val)

Most module writers would probably use `rawset` directly anyway, because
it is compatible with Lua 5.x (for x < 3). I think the current approach
is `var = nil` somewhere at top level, which is also backwards
compatible. So, IMHO, a new keyword would do more harm than good ...

>
> 2: _STRICT is a value that is global and defaults to `false` (or nil,
> but one must be able to assign it globally).

Why not just preload `strict.lua` instead?! Then people can `require` it
if they want to. But I'd rather use something that works offline (at
compile time), or at least can be enabled/disabled on a per-chunk basis
(maybe as a fallback to the offline tool).

>
> Thanks!
>
> -Andrew
>

Philipp



Reply | Threaded
Open this post in threaded view
|

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

Peter Melnichenko
In reply to this post by Andrew Starks
> Steve brought up Lua gotchas in a different context. I didn't have
> "strict" loaded and had a long bout with a hidden bug, leading me wish
> that strict global creation was a more integral part of Lua.
>
> ##Motivation and Acknowledgement of Existing Alternatives:
> [...]

I wonder if you have considered any static analysis solutions. A naive approach would be to look for global-related byte codes in the output of `luac`, filtering allowed globals. Also, there are plenty of metalua-based snippets on the wiki page[1]; I'd shamelessly plug my own[2].

Static analysis solutions don't slow the program at all, there is no need to worry whether the all code are executed when testing, and assigning a global, if needed, is simply `_G.key = value`.

> Thanks!
>
> -Andrew

Peter

[1] http://lua-users.org/wiki/DetectingUndefinedVariables
[2] https://github.com/mpeterv/luacheck

Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
In reply to this post by Dirk Laurie-2


On Sunday, March 30, 2014, Dirk Laurie <[hidden email]> wrote:
2014-03-30 19:57 GMT+02:00 Andrew Starks <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;andrew.starks@trms.com&#39;)">andrew.starks@...>:

> 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

 
Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
In reply to this post by Philipp Janda


On Sunday, March 30, 2014, Philipp Janda <[hidden email]> wrote:
Am 30.03.2014 19:57 schröbte Andrew Starks:

I think it's bad, because it might be motivation to not use strict or
to consider it a "hack."

It *is* a hack. An impressive one because it achieves a lot with little code, but on the other hand it modifies a shared resource, so it affects other people's code, and prevents them from setting a metatable on `_G` themselves (or at least makes it harder). And as you already mentioned, there are a lot of alternatives (most of which I consider superior to `strict.lua`), and this is my main motivation not to use `strict.lua` ...


##Proposal

My idea (probably not a new one) is in two parts:

1: `global` keyword is (probably) shorthand for rawset(_ENV, var, val)

Most module writers would probably use `rawset` directly anyway, because it is compatible with Lua 5.x (for x < 3). I think the current approach is `var = nil` somewhere at top level, which is also backwards compatible. So, IMHO, a new keyword would do more harm than good ...


If 5.3 has new keywords, then global is just one more parser issue to trap, so it's not a big deal to trap this one too.  

2: _STRICT is a value that is global and defaults to `false` (or nil,
but one must be able to assign it globally).

Why not just preload `strict.lua` instead?! 

I can do that. My point is that a natural method would make it more pervasive and less likely to be imemented in conflicting ways. 

Then people can `require` it if they want to. But I'd rather use something that works offline (at compile time), or at least can be enabled/disabled on a per-chunk basis (maybe as a fallback to the offline tool).

 I think that my suggestion achieves that with _STRICT

I might be missing something, though. 

Thanks!

-Andrew


Philipp




 
Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
Am 30.03.2014 23:16 schröbte Andrew Starks:
>>
> If 5.3 has new keywords, then global is just one more parser issue to trap,
> so it's not a big deal to trap this one too.

So far 5.3 doesn't have new keywords. It has new bitwise operators, but
luckily most modules/programs can live without those. Undefined globals
are more common (at least in my code), e.g. unpack, setfenv, loadstring,
jit. (I recently looked at some OO modules, and some of them still put
classes in the environment table.)

>
>>
>>> 2: _STRICT is a value that is global and defaults to `false` (or nil,
>>> but one must be able to assign it globally).
>>>
>>
>> Why not just preload `strict.lua` instead?!
>
>
> I can do that. My point is that a natural method would make it more
> pervasive and less likely to be imemented in conflicting ways.

It would be `require( 'strict' )` vs `_STRICT = true`. The first one is
already pervasive (and quite natural) for all people using `strict.lua`.
And what's wrong with conflicting implementations (as long as you use
only one at a time)?

>
> Then people can `require` it if they want to. But I'd rather use something
>> that works offline (at compile time), or at least can be enabled/disabled
>> on a per-chunk basis (maybe as a fallback to the offline tool).
>>
>>   I think that my suggestion achieves that with _STRICT
>
> I might be missing something, though.

The value of a global variable is a dynamic thing, so it is not
restricted to a certain chunk. You would need something like:

     local old_STRICT = _STRICT
     _STRICT = false
     local val = mod.func() -- call function in a non-strict module
     _STRICT = old_STRICT

and that would disable strict checking for all functions called via
`mod.func()`, even the ones defined in a "strict module".

You could make something like `require 'strict'()` work per-chunk using
the same techniques as the infamous `module` function. It would still be
redundant for me because I use static checking anyway, but at least it
wouldn't get in the way ...


Philipp




Reply | Threaded
Open this post in threaded view
|

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

Tim Hill
In reply to this post by Dirk Laurie-2

On Mar 30, 2014, at 11:36 AM, Dirk Laurie <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks


On Sunday, March 30, 2014, Tim Hill <[hidden email]> wrote:

On Mar 30, 2014, at 11:36 AM, Dirk Laurie <<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;dirk.laurie@gmail.com&#39;)">dirk.laurie@...> 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. 
Reply | Threaded
Open this post in threaded view
|

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

Coroutines
In reply to this post by Tim Hill
On Sun, Mar 30, 2014 at 4:09 PM, Tim Hill <[hidden email]> wrote:

On Mar 30, 2014, at 11:36 AM, Dirk Laurie <[hidden email]> 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

I like strict.lua but I think it should remain as a separate optional module distributed with Lua (whatever did happen to the etc/ dir in Lua's distribution?  someone told me it was last seen in 5.1).

I also take issue with strict.lua's implementation.  From what I remember, the original sets a metatable on _G, which (imo) is destructive/bad.  A better way (for 5.2) would be replacing _ENV with a proxy table that contains two members (_G & _ENV).  This way you can't some_env_global = 'cat' but you can _ENV.some_global = 'cat' and you still have access to _G for "really really globals" (haha).  I dunno, I just squirm at the thought of anything setting a metatable on _G, it feels sinful.

PS: The proxy table should define __newindex/index (of course), but also __len, __pairs, __ipairs, and __eq -- that should cover the common cases of how _ENV might be used.

PPS: It's important to remember that _ENV is strict.lua's _G. :>
Reply | Threaded
Open this post in threaded view
|

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

Philipp Janda
In reply to this post by Tim Hill
Am 31.03.2014 01:09 schröbte Tim Hill:

>
> [...]
>
> 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.
That's not true. It's just that the `strict.lua` provided by the Lua
authors *as an example* does not handle that case (to keep it simple, I
guess). You can have each module author choose the method he/she wants
to use to catch unwanted globals, no policy needed here at all. This is
obviously true for static offline approaches, and for the dynamic
approaches I've thrown together and attached a proof of concept based on
the original `strict.lua`. Use it via

     require 'mstrict'()  -- notice the extra pair of parentheses

in every file you want to. No third party modules are harmed in the
process. Global assignments at the top level still count as
declarations. Have fun!

>
> [...]
>
> —Tim
>

Philipp


mstrict.lua (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

steve donovan
On Mon, Mar 31, 2014 at 2:31 AM, Philipp Janda <[hidden email]> wrote:
>     require 'mstrict'()  -- notice the extra pair of parentheses
>
> in every file you want to. No third party modules are harmed in the process.
> Global assignments at the top level still count as declarations. Have fun!

Now there's a creative solution - nice one!

Reply | Threaded
Open this post in threaded view
|

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

steve donovan
In reply to this post by Peter Melnichenko
On Sun, Mar 30, 2014 at 10:20 PM, Peter Melnichenko
<[hidden email]> wrote:
> Static analysis solutions don't slow the program at all, there is no need to worry whether the all code are executed when testing, and assigning a global, if needed, is simply `_G.key = value`.

I'm also a fan of static analysis, although I use the classic bytecode
analysis approach (lglob).  It's been so useful that I bind my
'compile' shortcut key to lglob for Lua.  A hundred or so milliseconds
later I know where my typos are, before even trying to run the
program.

Reply | Threaded
Open this post in threaded view
|

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

Tim Hill

On Mar 30, 2014, at 11:29 PM, steve donovan <[hidden email]> wrote:

> On Sun, Mar 30, 2014 at 10:20 PM, Peter Melnichenko
> <[hidden email]> wrote:
>> Static analysis solutions don't slow the program at all, there is no need to worry whether the all code are executed when testing, and assigning a global, if needed, is simply `_G.key = value`.
>
> I'm also a fan of static analysis, although I use the classic bytecode
> analysis approach (lglob).  It's been so useful that I bind my
> 'compile' shortcut key to lglob for Lua.  A hundred or so milliseconds
> later I know where my typos are, before even trying to run the
> program.
>

Agreed. If it were me I’d prefer an editor/analyzer/compiler solution to one involving run-time overhead (though, of course, in many cases “compile time” is part of “run time” for many Lua scripts, but you know what I mean).

—Tim


Reply | Threaded
Open this post in threaded view
|

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

steve donovan
On Mon, Mar 31, 2014 at 9:13 AM, Tim Hill <[hidden email]> wrote:
> Agreed. If it were me I'd prefer an editor/analyzer/compiler solution to one involving run-time overhead (though, of course, in many cases "compile time" is part of "run time" for many Lua scripts, but you know what I mean).

I do think that Peter's approach of actual source analysis is going to
be the winner eventually, because there's only so much you can do with
the bytecode itself without context.

However, I was pleasantly surprised at how far you can get.  lglob
does (optionally) some dynamic things - it will pull in requires so it
can check the names of imported modules, and tracks aliases to
modules. E.g. this will be flagged as an error, since 'cwd' is not in
'lfs'.  Likewise 'math.sine' and so forth.

local lfs = require 'lfs'
print(lfs.cwd())

The point of this digression:  run-time checking can be generalized as
well, so that 'math.sine' is an error. This is why pl.strict
generalizes the 'strict.lua' pattern so that modules may be strict as
well:

https://github.com/stevedonovan/Penlight/blob/master/lua/pl/strict.lua

Reply | Threaded
Open this post in threaded view
|

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

Luiz Henrique de Figueiredo
In reply to this post by Coroutines
> (whatever did happen to the etc/ dir in Lua's distribution?
> someone told me it was last seen in 5.1).

The interesting bits are available at http://www.lua.org/extras/5.2/

It's easier to maintain them separately from the tarball.

Reply | Threaded
Open this post in threaded view
|

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

Coroutines
On Mon, Mar 31, 2014 at 4:03 AM, Luiz Henrique de Figueiredo <[hidden email]> wrote:
> (whatever did happen to the etc/ dir in Lua's distribution?
> someone told me it was last seen in 5.1).

The interesting bits are available at http://www.lua.org/extras/5.2/

It's easier to maintain them separately from the tarball.


Ahh, thank you kind marmot :-)
Reply | Threaded
Open this post in threaded view
|

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

Andrew Starks
In reply to this post by Philipp Janda


On Sunday, March 30, 2014, Philipp Janda <[hidden email]> wrote:
Am 31.03.2014 01:09 schröbte Tim Hill:

[...]

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.

That's not true. It's just that the `strict.lua` provided by the Lua authors *as an example* does not handle that case (to keep it simple, I guess). You can have each module author choose the method he/she wants to use to catch unwanted globals, no policy needed here at all. This is obviously true for static offline approaches, and for the dynamic approaches I've thrown together and attached a proof of concept based on the original `strict.lua`. Use it via

    require 'mstrict'()  -- notice the extra pair of parentheses

in every file you want to. No third party modules are harmed in the process. Global assignments at the top level still count as declarations. Have fun!


[...]

—Tim


Philipp


Thank, everyone. My mind is changed and I've been educated. I now see why things are the way that they are. 

I said there err new keywords when I meant more operators. I now understand that to be a very significant difference (from dirk's fork).  

I concede my points. Maybe as in "continue -> goto", there might be some kind of tweak that brings about a bit more of the flavor of what I was reaching for, with my thought. 

But, your kind responses helped me understand much. I will find some time in the next month to play with the world of static analysis. 

Thank you, Internet! :)

-Andrew
Reply | Threaded
Open this post in threaded view
|

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

Thomas Jericke
On 03/31/2014 12:00 PM, Andrew Starks wrote:


On Sunday, March 30, 2014, Philipp Janda <[hidden email]> wrote:
Am 31.03.2014 01:09 schröbte Tim Hill:

[...]

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.

That's not true. It's just that the `strict.lua` provided by the Lua authors *as an example* does not handle that case (to keep it simple, I guess). You can have each module author choose the method he/she wants to use to catch unwanted globals, no policy needed here at all. This is obviously true for static offline approaches, and for the dynamic approaches I've thrown together and attached a proof of concept based on the original `strict.lua`. Use it via

    require 'mstrict'()  -- notice the extra pair of parentheses

in every file you want to. No third party modules are harmed in the process. Global assignments at the top level still count as declarations. Have fun!


[...]

—Tim


Philipp


Thank, everyone. My mind is changed and I've been educated. I now see why things are the way that they are. 

I said there err new keywords when I meant more operators. I now understand that to be a very significant difference (from dirk's fork).  

I concede my points. Maybe as in "continue -> goto", there might be some kind of tweak that brings about a bit more of the flavor of what I was reaching for, with my thought. 

But, your kind responses helped me understand much. I will find some time in the next month to play with the world of static analysis. 

Thank you, Internet! :)

-Andrew
I have something to cheer you up a little:
http://lua-users.org/lists/lua-l/2002-04/msg00177.html

See, the Lua team was there already. For me it's a petty that they dropped those ideas. I have myself a metatable on the globals to support this stuff. But a general solution to such a basic problem would be nice.

--
Thomas
Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2014-03-31 15:15 GMT+02:00 Thomas Jericke <[hidden email]>:

> http://lua-users.org/lists/lua-l/2002-04/msg00177.html
>
> See, the Lua team was there already. For me it's a petty that they dropped
> those ideas. I have myself a metatable on the globals to support this stuff.
> But a general solution to such a basic problem would be nice.

Some history:

1993 Lua released.
1995 Lua 2.1 provides fallbacks.
1997 Lua 3.0 replaces fallbacks by tag methods.
2003 Lua 5.0 replaces tag methods by metamethods.
2011 Lua 5.2 stores globals in _ENV.

I would not say that the Lua team dropped the ideas. On the contrary,
starting just the year after that post, they present a general solution so
basic that user control over globals is merely one of the many things
it solves.

Honestly, I can't understand the squeamishness some people have
about _ENV. You are allowed to treat it like any other table, including
equipping it with metamethods, so do it. That is not dodgy programming,
it is exploiting features the designers meant to make available to you.

strict.lua is not supposed to be a tool everybody should use, it is
a sample module demonstrating just one powerful thing that
metatables allow you to do. This is how Teacher paints a cat,
now you go and paint a leopard for me.

And _G. There's nothing sacred about _G. It's merely another name
for the table containing the lowest-level _ENV. The only claim made
for _G in the Lua manual is that nothing in Lua and its libraries ever
changes _G. That's not because _G is a holy cow, it is because
_G is good for nothing besides stopping the first _ENV from being
garbage-collected. _G is not being worshipped, it is being ignored.

12