RE: Making vars local by default

["Eric Ries" <eries@...>]

This is only tangentially related to this discussion, but I feel it may
affect the Lua-as-language vs Lua-as-configfile line up.

I am curious if it would be worthwhile to implement a perl-style eval() for
executing lua code. Lua's dostring() is very close, but eval() has the added
advantage of automatically returning the last statement executed. So for
instance eval( "10" ) is equivalent to dostring( "return 10" )

I have found this behavior to be especially useful in both scripting
language and config file contexts. In fact, I think we could probably expand
upon it, perhaps deciding on some additional behaviors that perl does not
have. In particular, I think it might be handy for eval() to return a table
of all of the expressions evaluated during the call. So the following two
would be equivalent

foo = eval( "function foo() ... end { a = 1, b = 2 }" )

foo = dostring( "return { function foo() ... end, { ... } }" )

Any thoughts?

Eric


> -----Original Message-----
> From: owner-lua-l@tecgraf.puc-rio.br
> [mailto:owner-lua-l@tecgraf.puc-rio.br]On Behalf Of Russell Y. Webb
> Sent: Tuesday, May 22, 2001 1:35 PM
> To: Multiple recipients of list
> Subject: Re: Making vars local by default
>
>
> > It's starting to become apparent to me that life would be easier if new
> > variables were
> > local by default, instead of global.
>
> I too have wished for this (as have several others).  The main problem is
> code compatibility and the perception that global-by-default fits better
> with Lua's role as a configuration language (in conflict with its
> role as a
> scripting language).
>
> Here's a thought.  How about introducing the key work "global"
> that for now
> does nothing (since that's the default behavior).  That means
> that new code
> can be written with explicit "global" notation (making it clearer in my
> estimation) and opens the possibility of having a code base one day that
> could without too much pain transition to a local by default rule
> (though it
> might not ever switch over).  Code written entirely in this new
> style could
> run in a modified Lua for those who think that's a feature.  Of
> course this
> new code will not run on old versions of Lua but that's often true with
> changes to Lua (like the for loop constructs).
>
> Another route is to disallow assignment to globals without
> passing through a
> function: global("name", new_value).  This can be done today and
> aside from
> making standard Lua code fail its only problem lies in the strange feeling
> syntax, but who really needs to write to globals very often anyway?
>
> Russ