true, false, and nil

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

true, false, and nil

Alan Watson-2
I keep banging up against the overloaded meaning of nil: something has
no value and something is false.

This overloading causes me problems when I have tables in which a
value can be absent, present and true, or present and false.

Furthermore, Lua is supposed to be useful as a configuration language.
Which of the following do you prefer?

	dothis = true
	dothat = false
	
	dothis = not nil
	dothat = nil

(A false solution to this second problem is to set "true = not nil".
This idea has been explored extensively in C which has a somewhat
similar problem. You end up with situtations where a variable can be
true but not equal to the value of "true", for example, the value "2"
is true, but is not equal to "not nil".)

Can someone persuade me that the current situation is a Good Thing
and that a proper boolean type would not be a great improvement?

Alan Watson

Reply | Threaded
Open this post in threaded view
|

Re: true, false, and nil

Alan Watson-2
> if you really need to distinguish between "absent" and "present and false",
> then, yes, you need a representation for false that is diferent from nil.
> for example, true=1 false=0

This means that the expression "not true == false" is false. I
wouldn't like to write, let alone revise, such a program. (Similar
arguments hold for "typedef enum { false, true } boolean;" in C.)

> on the other hand, i think the "right" way to handle defaults is to use
> the "index" tag method, if you want to make distinguish between "absent" and
> "present and false",

I don't understand what you mean. Can you elaborate, please?

> for configuration, i prefer:
> 
> writelog=nil
> sendmail=1

To use Hermia's words from A Midsummer Night's Dream: "I am amazed,
and know not what to say."

> i'm not trying to persuade you of anything, of course.
> but we don't think we need a boolean type.

Well, can you at least help me understand why you made this design
decision. For example, can you give me a single advantage of the
current design over one with a true boolean? I just don't get it.

Regards,

Alan Watson

Reply | Threaded
Open this post in threaded view
|

Re: true, false, and nil

David Jeske-2
In reply to this post by Alan Watson-2
I agree 100% with Alan here.

I really dislike using "nil" to mean anything other than "absent".

On Thu, Dec 04, 1997 at 05:02:32PM -0200, Alan Watson wrote:
> I keep banging up against the overloaded meaning of nil: something has
> no value and something is false.
> 
> This overloading causes me problems when I have tables in which a
> value can be absent, present and true, or present and false.
> 
> Furthermore, Lua is supposed to be useful as a configuration language.
> Which of the following do you prefer?
> 
> 	dothis = true
> 	dothat = false
> 	
> 	dothis = not nil
> 	dothat = nil
> 
> (A false solution to this second problem is to set "true = not nil".
> This idea has been explored extensively in C which has a somewhat
> similar problem. You end up with situtations where a variable can be
> true but not equal to the value of "true", for example, the value "2"
> is true, but is not equal to "not nil".)
> 
> Can someone persuade me that the current situation is a Good Thing
> and that a proper boolean type would not be a great improvement?
> 
> Alan Watson
> 

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Visual Lua

Steve Dekorte-2
Is there a web page for the "Visual Lua" research project?

Steve Dekorte

Reply | Threaded
Open this post in threaded view
|

locals again

Russell Y. Webb
Since my last posting about locals I've spent a 
fair amount of time thinking about the issue.  I still
think defaulting to global access is a real problem for
me.  While explaining Lua to some folks for whom I wrote 
a little preprocessor using Lua, I realized that explaining
and supporting the global default model to semi-technical
users is not ideal.

Yesterday, I sat down to work with setting up tag methods 
to at least deliver runtime warnings.  My idea was to make 
it illegal to access globals unless their name started with 
'g' and the second letter was a capital.  As some of you 
probably know, I found that you can't set the get and set
global methods for some built-in types.  Looking at the 
C source code this seems to be prevented by a valid_events
table.  Can I change that table and get access to those
tags?

Anyway, there only seems to be a few other solutions:

1. a method type function definition that defaults to
local.  This could be considered a complication to the
language, but one doesn't have to even explain it to 
users (actually, some of use would stop explaining the
current function...end statement).
	method f(x)
		y=10 -- this is a local
		return x+y
	end
	
2. a preprocessor that modifies source code (I haven't
been able to figure out a complete solution this way).

3. an option to change the access mode when Lua is 
compiled or dynamically from within Lua.

Does anyone agree that this is a problem?  If everyone 
else is happy with global access, please excuse my 
persistance.

To clarify, my basic problem is that default global 
access easily turns typo-bugs into really difficult
ones (that can be extremely execution order dependant).
Creating and accessing globals inadvertantly also makes
writing a long up-time, multi-user, scriptable program 
almost impossible.

Thanks for your consideration,
Russ Webb

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Luiz Henrique de Figueiredo
I`m replying to the list before this turns into a major "war" about
taste in language design.

>From [hidden email] Thu Dec 11 10:52:12 1997

>Since my last posting about locals I've spent a 
>fair amount of time thinking about the issue.  I still
>think defaulting to global access is a real problem for me.

Of course, the easy answer here is:
	"if it's a real problem for you, do not use Lua." :-)
However, I'm not looking for easy answers here.

Making all variables global by default was a decision taken in the very early
days of the design.
The rationale is that Lua is designed to be used as a configuration language,
where end users will hardly ever write their own functions.
Now imagine the mess of having to write

	global fgcolor="red"
	global bgcolor="white"
	global tolerance=0.001

This seems quite verbose and useless, from the point of view of the end user.
So the decision of having globals by default makes sense to us ;-) and
we don't feel we need to change it.
Moreover, we cannot change it without breaking *lots* of Lua code.

>While explaining Lua to some folks for whom I wrote 
>a little preprocessor using Lua, I realized that explaining
>and supporting the global default model to semi-technical
>users is not ideal.

Really? Do semi-technical users prefer/understand local variables??

>To clarify, my basic problem is that default global 
>access easily turns typo-bugs into really difficult
>ones (that can be extremely execution order dependant).

I admit that typos can created subtle bugs.
After all, experts need to write Lua code to be used by end users,
and the experts need ways to write safe code.

Now, name clash is not a problem with Lua as a language, but rather with how
it is used.
Name clash occurs in C too.
Try defining your own malloc with a different semantics and see what happens.
Try #including <math.h> and have global variables called y0,y1,yn,gamma.

Having said this, Lua does provide ways to cope with name clashes, if this
is a problem for you. Just don't expect this to be as easy as a 'global'
keyword in front of everything. Experts pay a price for their expersise
(and they can charge too!).
This is Lua's philosophy of being simple while being extensible.
In this case, the simplest thing is to make everything global.
But Lua is extensible and allows you to change this simple default if needed.
You just have to write some (maybe subtle) code for this.

The FAQ describes one way to avoid name clashes, which I'll expand below.

>Yesterday, I sat down to work with setting up tag methods 
>to at least deliver runtime warnings.  My idea was to make 
>it illegal to access globals unless their name started with 
>'g' and the second letter was a capital.

You're right, that's a perfect application for tag methods!

>As some of you 
>probably know, I found that you can't set the get and set
>global methods for some built-in types.

Right. This is because strings and numbers are not objects but just values.
Consider the code below:

	a=1	b=a
	c={}	d=c

a and b have the same value but the two '1' are "different".
if you now do a=2 then b is still 1.
c and d have the same value and it it's shared.
if we now do d.x=1 then c.x will be 1.
so, tag methods can be set for table values but not for numbers or strings.

>Looking at the 
>C source code this seems to be prevented by a valid_events
>table.
>Can I change that table and get access to those tags?

Sure, you can do that in your copy of Lua. (But don't redistribute!)
But I think you'll get into a mess, as described above.

The solution for this is never to store simple values in global variables,
but rather acces them through a table (for which you *can* set tag methods).
The FAQ describes a similar solution for creating read-only variables.

So, to implement your idea of only having globals named g[A-Z]..., you could:
(CAUTION: untested code ahead)

0. create a tag for tables representing globals:
	gGtag=newtag()
	
1. set the 'get/setglobal' tag methods for the nil tag to create a table
   with tag gTag with a single field value containing the actual value:

   function gGsetglobal0(x,v)
	if badname(x) then error("`"..x.."' not a global variable") end
	local t={value=v}
	settag(t,gGtag)
	return t
   end

   function gGgetglobal0(x)
	if badname(x) then error("`"..x.."' not a global variable") end
	return nil
   end

   settagmethod(tag(nil),"setglobal",gGsetglobal0)
   settagmethod(tag(nil),"getglobal",gGgetglobal0)

   This will catch all accesses to undefined variables and only allow
   "good" names to be used as global variables.

2. set the 'get/setglobal' tag methods for good names:

   function gGsetglobal(x,old,new)
	old.value=new
	return new
   end

   function gGgetglobal(x,v)
	return v.value
   end

   settagmethod(gGtag,"setglobal",gGsetglobal)
   settagmethod(gGtag,"getglobal",gGgetglobal)

I hope this is clear and works for you.

>Does anyone agree that this is a problem?  If everyone 
>else is happy with global access, please excuse my 
>persistance.

I'm interested in what other people think about this "problem".
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Russell Y. Webb
Thanks for the well thought out reply.  I'll try to look through your 
code this afternoon.

> Now imagine the mess of having to write
> 
> 	global fgcolor="red"
> 	global bgcolor="white"
> 	global tolerance=0.001
> 
> This seems quite verbose and useless, from the point of view of the end user.
> So the decision of having globals by default makes sense to us ;-) and
> we don't feel we need to change it.
> Moreover, we cannot change it without breaking *lots* of Lua code.

Sorry I wasn't clear.  I'm suggesting a change that would only change
global access within a "method...end'' block.  It wouldn't break any code,
but it would make Lua more capable of supporting different programming
methods and goals.  I really love Lua and respect all the design choices
that went into it.  For my needs, having a default-to-local access block
for functions would be of great help.  I'd add it to the language myself,
but I haven't yet been able to unravel the mystery that is the parser. 

To summarize my suggestion:
1. within a method...end block, all variable access and assignment is 
   assumed to be local 
2. the global keyword (only needed inside method...end) means, the
   very next word is a global variable name

Seems simple enough to me.  If I could get some pointers on how to add it
myself (is there a lex file we don't have?), I'd be happy to produce an
experimental Lua (not for distribution of course) so we could try it
out. 
 
> Really? Do semi-technical users prefer/understand local variables??

I should have called them technical people who aren't serious 
programmers.  The type who run plasma etchers and program RPN calculators.

Thanks,
Russ

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Fred Bertsch
In reply to this post by Luiz Henrique de Figueiredo
On Thu, 11 Dec 1997, Luiz Henrique de Figueiredo wrote:

> I'm interested in what other people think about this "problem".
> --lhf

I'm currently trying to use Lua as an extension language for a video game.
For this, I will need to let users write functions which will be used as
methods in a C++ library.  Users will only have to create global
functions, and they will never need to create a global
variable.  (Unless they're doing something really horrible.)  They will,
however, need to access global variables and functions.

Except for the requirement for a "local" keyword, Lua look like an
ideal language for me.  It's reasonably fast, very flexible, and well
thought out.  In addition, it looks as though it can be made
somewhat secure.  While Java is the obvious choice, I like the size and
simplicity of Lua better.  

Obviously, if a large amount of code is going to be written in Lua,
something is going to have to be done to avoid deadly typos caused by
forgetting a "local" somewhere.  Of the methods which Russ and you
suggest, I'd have to say that the ideal solution for me would be something
along the lines of the "method" that Russ suggested.  This would not break
old code, but would make functions easier to both read and write.  

As long as I'm wishing for additions to the language, I'll list one more.
I'm hoping to send precompiled code over the network to execute on client
machines.  The only way to do this currently appears to be to save the
code in a file, and then use lua_dofile() on it.  In order to avoid
cluttering the filesystem and speed things up, I'd like something
similar to lua_dostring() which executes on a block of precompiled code
which resides in memory.  Does anyone know how to do this?

-Fred

Reply | Threaded
Open this post in threaded view
|

source for functions

Steve Dekorte-2
In reply to this post by Russell Y. Webb
Is there any way to ask Lua for the source code of a function?
If not, what's the best way to add this feature?

This is an important feature for a dynamic system like Lua because you
never now if your external source matches what's in the system. So any
sort of graphical object browser(I'm working on one) is going to need this.

This would also allow Lua to be able to save an image of the system from
withing Lua.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: locals again

David Jeske-2
In reply to this post by Luiz Henrique de Figueiredo
Since the last time the local/global discussion came up, I've been
thinking about it alot as well. I sometimes feel that the "implicit"
globals can cause trouble, however, I _like_ the more structured idea of
"declaring" local variables. 

I agree that doing "global varname = <stuff>" would make using Lua very
troublesome. One might decide to make global variables work without a
preface at the "top" level, but yet require a global declaration in
functions. However, this introduces two different syntax for the same
operation (IMHO bad).

I've come to the following conclusions:

  - The current style for implicit globals and declared locals is
    simple, and achieves the goal of making Lua an easy to use,
    and powerful configuration and extension language. 

  - It would be useful, _at times_, to require that global variable
    access within functions be declared specifically. By this, I 
    mean that NO undeclared variable access from within a 
    function would be valid. One would do:

       function boo()
                 local a,b,c;
                 global p,q,r;

                 a = p; b = q; c = r;  -- valid
                 z = 2; -- parse level error
       end

    I also realize that this would only be desirable for advanced
    programmers working on the supoprting code of their system.
    
  - I think the introduction of the keyword "method" (as suggested)
    would be a BAD idea. There is already some confusion in 
    beginning users about the "exposed" method syntax. (i.e. how
    function a_name(self,a,b)   ==   function tbl:a_name(a,b) )
    I think that adding a keyword method which had the same properties
    would confuse things, primarily because of the connotations
    that "method" is going to hold for programmers familiar with
    class based programming.

  
So my solution would be to add another directive like "$debug$" which
would tell the parser to turn on strict variable declaration syntax. I
would have to decide if this strict syntax would be required for the
"main()" body of code (i.e. top level code in a lua file) while this
directive was on.

** run-time solution

An acceptable run-time solution for me would be to prevent accidental
global variable creation or destruction. All global variables would be
created or destroyed through functions, and access to them would remain
the same as it is now. However, this would prevent any existing code
relying on the old behavior from working.

ex:

  newglobals("a","b");
  
  a = 3; -- valid
  b = a; -- valid

  a = nil; -- valid,  the name is still valid, even if the variable is nil
  a = 4;   -- valid

  c = 5; -- invalid (run-time error)

  deleteglobals("a","b");

  a = 3; -- invalid (run-time error)

end ex.

I believe this should be easy to achieve using tag methods similar to
those described to implement the previous solution.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: source for functions

David Jeske-2
In reply to this post by Steve Dekorte-2
To further elaborate on Steve's requests...

On Thu, Dec 11, 1997 at 05:29:53PM -0200, Steve Dekorte wrote:
> Is there any way to ask Lua for the source code of a function?
> If not, what's the best way to add this feature?

Steve and I have been talking about his work on a Graphical development
environment for Lua. (he's writing it under OpenStep) It would be
convinent to be able to access VM code bytes and source code. Accessing
the VM bytes is not difficult. However, the source is parsed and thrown
away. We were thinking about changing the parser so that it would store
the source code for function blocks as it parsed them, and attach them to
the object. Not all function objects would have source attached, but if
one did, then you wouldn't have to look any further for the source.

This is leading down the path to a more "smalltalk like" development
system where you work within an image, and make changes within the system,
and then "persist" out the whole system. The system can then be loaded in
back to it's original state. 

There are also a few problems with connections to the outside world. 
Whether it's an open file descriptor, or some C code holding a lua_ref to
something, re-creating this attachment when the image is reloaded can be
troublesome. 

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Alan Watson-2
In reply to this post by Russell Y. Webb
> To clarify, my basic problem is that default global 
> access easily turns typo-bugs into really difficult
> ones (that can be extremely execution order dependant).

Since typos also occur in local variable and field names, isn't this
problem always going to exist in some form?

Regards,

Alan

Reply | Threaded
Open this post in threaded view
|

Re: locals again

David Jeske-2
On Thu, Dec 11, 1997 at 08:03:30PM -0200, Alan Watson wrote:
> > To clarify, my basic problem is that default global 
> > access easily turns typo-bugs into really difficult
> > ones (that can be extremely execution order dependant).
> 
> Since typos also occur in local variable and field names, isn't this
> problem always going to exist in some form?

No. What the original poster was talking about is the problem of not
_noticing_ when you have a local variable typo.

For example:

function test()
     local test_one, test_two, test_three;

     test_one = 1;
     test_two = 2;
     test_tree = 3;
end

Notice the misspelling of "test_three" as "test_tree". THIS is what
we are trying to prevent. In lua, not only do you not notice at compile,
you don't even notice at RUNTIME! Not unless you happen to make a global
called "test_tree", or you happen to print the global variables or
something.

So we're trying to specify some approach for making this kind of error not
possible. My preference (for my own stuff) is to change the parser so that
you have to explicitly declare what globals you are going to access in a
function if some "strong global checking" is enabled. The above would
signal a syntax error which could be corrected either by adding the
directive:

    global test_tree;

To the top of the function (if this is what the code was supposed to do)
or by fixing the spelling of the line to be:

     test_three = 3;

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: source for functions

Luiz Henrique de Figueiredo
In reply to this post by Steve Dekorte-2
>From [hidden email] Thu Dec 11 17:29:05 1997
>
>Is there any way to ask Lua for the source code of a function?

no. don't you mean bytecodes instead of source?

>If not, what's the best way to add this feature?

depends. why do you need this?

>This is an important feature for a dynamic system like Lua because you
>never now if your external source matches what's in the system.

you lost me here. can you give an example?

>This would also allow Lua to be able to save an image of the system from
>withing Lua.

i'm actually working on this but it's hard (because of cycles in data
structures and such). and we'd like it to be general.
if you only want to save bytecodes, then it's easy and most of what is needed
is already available in luac.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: source for functions

Steve Dekorte-2
>>Is there any way to ask Lua for the source code of a function?
>no. don't you mean bytecodes instead of source?

Nope (explained below)

>>If not, what's the best way to add this feature?
>depends. why do you need this?

I'm writing a Lua object browser. When I click on an Object and then select
a slot that holds a function, I want it to be able to bring up the source
code for it.

>>This is an important feature for a dynamic system like Lua because you
>>never now if your external source matches what's in the system.
>you lost me here. can you give an example?

For example, in the case of my object browser -
Let's say it browsed my source code instead of Lua. This would not
always reflect what was in Lua since I can change/add/remove
attributes and methods at runtime. So the only reasonable approach
is to look directly at the system, not the source. And I can do
that for everything (tables, attributes) with the exception of functions.

>This would also allow Lua to be able to save an image of the system from
>withing Lua.
>
>i'm actually working on this but it's hard (because of cycles in data
>structures and such). and we'd like it to be general.
>if you only want to save bytecodes, then it's easy and most of what is needed
>is already available in luac.

I think adding the ability to get the source for a function at runtime
might be a required step no matter which way imaging is implemented.

Steve Dekorte

Reply | Threaded
Open this post in threaded view
|

Re: source for functions

Stephan Herrmann-2
In reply to this post by Steve Dekorte-2
Steve Dekorte <[hidden email]> writes:

> Is there any way to ask Lua for the source code of a function?
> If not, what's the best way to add this feature?
Of course, there is a way, not builtin, but rather through -- guess -- 
tag-methods. Something like:

FunctionTag=newtag("table")

function callFunction (m, ...)
    call (m.func, arg)
end

settagmethod(FunctionTag, "function", callFunction)

function compileFunction (name)
    local descriptor=getglobal(name)
    dostring(descriptor.source)
    descriptor.func=getglobal(name)
    setglobal(name, descriptor)
    settag(descriptor, FunctionTag)
end

-- now you need a table wrapping every function:
myPrint={source="function myPrint (a) print(\"myprint says:\",a) end"}
compileFunction("myPrint")

-- call and print the function:
myPrint("Here we are")
print(myPrint.source)

Of course definition of functions is not straight-forward, but within 
a programming environment this might be wrapped at the user-interface, right?

As question remains: should we be able to access the byte code from within
lua for dumping/undumping etc.?

Does this in some way or other meet your requirements?

Cheers
Stephan

Reply | Threaded
Open this post in threaded view
|

lua_dobuffer

Fred Bertsch
In reply to this post by David Jeske-2
Earlier, I asked about a way to execute some precompiled code that was in
memory.  Someone mentioned lua_dobuffer, but I deleted the message.

Anyway, here's my followup question:  While dobuffer appears to do exactly
what I want it to do, it's not part of the standard API.  Will it still be
there Lua 3.1?  How about later versions?

Thanks,
Fred

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Steve Dekorte-2
In reply to this post by David Jeske-2
>function test()
>local test_one, test_two, test_three;
>
>test_one = 1;
>test_two = 2;
>test_tree = 3;
>end
>
>Notice the misspelling of "test_three" as "test_tree". THIS is what
>we are trying to prevent. In lua, not only do you not notice at compile,
>you don't even notice at RUNTIME! Not unless you happen to make a global
>called "test_tree", or you happen to print the global variables or
>something.

I've run into these problems as well.

>global test_tree;

Here's another solution, no globals - actually only one global table named
'global' or 'lobby' or something. This would also make Lua more consistant
and eliminate the need for all the 'global' APIs.

So when you wanted to set a global, would would do:

global.mySlot = "blah"

Another plus is that you would no longer have to declare local variables.
Any variable that doesn't begin with self or global can be assumed local.

What do you guys think?

Steve

Reply | Threaded
Open this post in threaded view
|

Re: locals again

Russell Y. Webb
> global.mySlot = "blah"
> 
> Another plus is that you would no longer have to declare local variables.
> Any variable that doesn't begin with self or global can be assumed local.

This method is like using a naming convention for global access and in my
opinion takes away for the language's style. 

I've been hacking on the Lua source to experiment with different options. 
I now have the following implemented: 

1. $globals, $noglobals to turn on and off global variable access inside 
functions.

2. a 'global' keyword like 'local' that turns on access within one 
function for the names in the list.

The good thing about this system is that code written with the 'global' 
and 'local' keywords works in $globals and in $noglobals mode.  Of course 
you get enhance error checking in $noglobals mode.

Example:
z=3
g=-56
function test() 
local x
global z,g
	x=z+g
	print(abs(x))
end

I've thought about experimentally making 'local' optional since it seems a
little redundant.  The problem with omitting it is that you can then 
write code which does different things depending on the access mode.  
That seems really confusing to me:

$globals
function g() x=3; end -- creates a global
$noglobals 
function g() x=3; end -- creates a local

That's bad.

The only way, I can think of, not to require the 'local' keyword (a nice
language simplification I think) is to have a 'method...end' syntax.  So
'method...end' automatically manages the Lua global access mode, sort of
like writing '$noglobals function...end $globals' all the time. 

There seems to be two good final forms to me:

1. $noglobals, $globals, require 'local' and 'global' lists to write code 
that works in either mode.
(Would $global [on|off] or something else be a better syntax?)

2. function...end, method...end, globals list required in methods and 
local list required in function
(Is there a better word than 'method' for this?)

I'm reasonable happy with either; they both have there advantages.  Option
1 has the advantage of creating a new coding standard that always works,
but may create some confusion as to what mode Lua is or even should be in
for a particular piece of code (especially confusing for those of use who
like to cut and paste code together).  Option 2 has the advantage of
clearly separating the access modes and only requiring one list of
variables (since one access mode is assumed).  Option 2 may confuse
beginner programmers as has been pointed out, but only one of the
constructs is required for any system, so just pick the one you like. 

Would anyone like to experiment with the modifications I made (all the
mods are in lex.c, parser.c, parser.h, and lua.stx)?  I'm just trying to
help people think about a standard Lua answer to this issue. 

I hope people aren't getting sick of this issue.

Russ Webb


Reply | Threaded
Open this post in threaded view
|

Re: locals again

Alan Watson-2
In reply to this post by Russell Y. Webb
> I've been hacking on the Lua source to experiment with different options. 
> I now have the following implemented: 
> 
> 1. $globals, $noglobals to turn on and off global variable access inside 
> functions.
> 
> 2. a 'global' keyword like 'local' that turns on access within one 
> function for the names in the list.

This looks very useful and I think it, or something like it, should be
considered for inclusion in the standard version.

Do these directives have any effect outside functions (i.e., at the
main level)?

Another option, and one that might be retroactively applied to the
$debug directive, would be to have a global table-like variable called
lua with members lua.debug and lua.defaultglobals that can be nil or
non-nil (and I hope you know how much it hurt not to say `true or
false' there). A suitable gettable/settable method would set the
internal C variable. I think this is cleaner, more flexible, and
better potential for growth than directives.

Other members could be lua.version, lua.stack, to get access to the
call stack, and lua.error, which would replace the seterrormethod
function.

> I've thought about experimentally making 'local' optional since it seems a
> little redundant.  

Unless I misunderstand what you've done, I don't think local
declarations are redundant. If you have non-declared names reference
local variables by default, any misspelled global name erroneously and
silently references a local variable. Clearly, this is an error just
as having misspelled global variables erroneously and silently
reference global variables. This is the kind of error you are trying
to prevent, yes?

Earlier I had voiced my concern that this did nothing for spelling
mistakes in table indices. However, I've realized that you can get
around this most of the time by defining appropriate table types with
settable/gettable methods that check the validity of the indices. Of
course, this will only give you a run-time error, but without a static
type system I don't think there's much else we can do.

> I hope people aren't getting sick of this issue.

I can't speak for anyone else, but I'm not getting sick of this at all.

Regards,

Alan Watson

12