Re: global

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

Re: global

Luiz Henrique de Figueiredo
>If i use e.g.
>global in nil
>
>then any code that is dofiled or something has to obey to this, or it 
>won't work. quite a mess for any Standard Libraries.
>Libraries suddenly depend on how the user wants to handle globals.

No: "global" respect scopes. dofile'd programas are not executed in the same
scope of the calling program; dofile is not include.

>or do you have to do something like this:
>global strfind,print
>global in nil

Yes. In either order, as Roberto explained.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: global

Luiz Henrique de Figueiredo
>so global doesn't affect dofile statements at all? 

No, neither does local. Change your example to "local a=123" and it'll print
nil twice.

>Really? Interesting. so i can't use global for sandboxes in which dofile 
>would be allowed?

I'm not sure what you mean here.

>The beauty in lua lies in the simplicity which still provides 
>uncomplicated and  powerful ways of doing things.
>This global statement somehow doesn't fit. it really looks like an 
>complex and complicated beast albeit the "simple" syntax.

You have a point. The syntax is simple but the semantics can get confusing.
The main issue is whether global declarations as proposed solve the
perceived need for global declarations.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: global

Luiz Henrique de Figueiredo
In reply to this post by Luiz Henrique de Figueiredo
>bar = 10;
>
>fuction foo()
>bar = 5; -- this bar is local to foo()
>print(bar);

How about "print"? Is it local too?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: global

Thomas Lavergne-3
In reply to this post by Luiz Henrique de Figueiredo
>>Really? Interesting. so i can't use global for sandboxes in which
>>dofile
>>would be allowed?
>
>I'm not sure what you mean here.
>

Personnaly, I'd love to do this if I need only one function in a file, 
but with your proposal it's impossible :

foo = {}
do
  global in foo
  dofile("foo.lua")
end
bar = foo.bar
foo = nil

-- 
Thomas Lavergne                       "Le vrai rêveur est celui qui rêve
                                       de l'impossible."  (Elsa Triolet)
[hidden email]                                             
[hidden email]    ICQ:#137121910     http://assoc.wanadoo.fr/thallium/



Reply | Threaded
Open this post in threaded view
|

Re: global

Björn De Meyer
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote:
> 
> >bar = 10;
> >
> >fuction foo()
> >bar = 5; -- this bar is local to foo()
> >print(bar);
> 
> How about "print"? Is it local too?
> --lhf

Hmmm... that is indeed a dificult question, 
seen the way LUA works with variables.
In PHP, print would remain global because it is a
builtin function (what I would want). However, in LUA, 
this would probably mean sacrificing orthogonality. 
You would need to add another rule in the spirit of 'if 
the variable refers to a builtin function, then it takes 
precedence above local definitions'. Which may not a good 
idea for LUA.

Still, I maintain that allowing function scope assignments to 
overwrite global scope variables is a bad idea. If forces 
programmers to know the name of all global variables and avoid 
them, to prevent them from being changed unadvertently. I wonder 
how the proposed global in ... statement brings adequate solace 
for that problem. 

I think I can sexplain my conundrum best with an example:

index = { "apple", "pear", "cherry" } 
-- I want the table 'index' to be globally accessible
-- but without the hassle of saying 'global' every time.
foo = function()
-- I want foo also to be globally accessible without a hassle
index = 0
-- But I want this 'index' to be local, without the hassle
-- of having to say 'local' or such every time.
print(index)
-- And to top it off, 'print' is the global print
end;

Yes, I want to have my bread and eat it. Perhaps some kind of
'super-global' scope could work here?

  





 




-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: global

Peter Prade
In reply to this post by Thomas Lavergne-3
> Personnaly, I'd love to do this if I need only one function in a file,
> but with your proposal it's impossible :
>
> foo = {}
> do
>   global in foo
>   dofile("foo.lua")
> end
> bar = foo.bar
> foo = nil

this wouldn't work - global in foo is not effecting the execution of
dofile("foo.lua") (except that the variable "dofile" is looked up in foo,
where it isnt found - i guess you didnt mean to do this)

what you want is this: (this already works with lua 4.0)
foo = {}
do
  local t = globals(foo) -- use foo instead of the old globals table. store
old globals table in t
  t.dofile("foo.lua")
  t.globals(t)
end
bar = foo.bar
foo = nil

Cheers,
Peter


Reply | Threaded
Open this post in threaded view
|

RE: global

Gambit
Isn't there a simple 'includefile' method out there that, ala #include, just inserts the relevent text? It strikes me that this would do exactly what Thomas is looking for, without requiring poisoning of his global tables.
-G

At 09:23 PM 4/19/2002 +0200, you wrote:
> Personnaly, I'd love to do this if I need only one function in a file,
> but with your proposal it's impossible :
>
> foo = {}
> do
>   global in foo
>   dofile("foo.lua")
> end
> bar = foo.bar
> foo = nil

this wouldn't work - global in foo is not effecting the execution of
dofile("foo.lua") (except that the variable "dofile" is looked up in foo,
where it isnt found - i guess you didnt mean to do this)

what you want is this: (this already works with lua 4.0)
foo = {}
do
  local t = globals(foo) -- use foo instead of the old globals table. store
old globals table in t
  t.dofile("foo.lua")
  t.globals(t)
end
bar = foo.bar
foo = nil

Cheers,
Peter


Reply | Threaded
Open this post in threaded view
|

Re: global

Roberto Ierusalimschy
In reply to this post by Björn De Meyer
> [It] forces programmers to know the name of all global variables and      
> avoid them, to prevent them from being changed unadvertently. I wonder  
> how the proposed global in ... statement brings adequate solace for     
> that problem.                                                           

The idea is that, optionally, you can have a declaration like

  global in nil

or

  global in {}

Then, any access to a non-declared variable wouldn't affect a global
variable (in the first option it would be an error, in the second it
would access a "static" variable). With proper support, we could have
other options, like

  global in ReadOnly(globals())

where you could only read undeclared global variables, but any write
would trigger an error.

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: global

Thomas Wrensch-2
Hello,

I've been reading the comments on the "global" declaration with some
interest. Many folks seem to have mixed feelings about it. Personally I
don't think I can make any important judgements until I've actually used a
version of Lua that contains the keyword. My suggestion would be to put
out a version (alpha, work, whatever) of the language that includes the
global declaration and give everyone a chance to play with it. After a few
months we'll have a much better idea of its usefulness, power, and costs.


   - Tom Wrensch



Reply | Threaded
Open this post in threaded view
|

Re: global

James Hearn
In reply to this post by Luiz Henrique de Figueiredo
> You have a point. The syntax is simple but the semantics can get
confusing.
> The main issue is whether global declarations as proposed solve the
> perceived need for global declarations.
> --lhf

I don't usually jump in on the language discussions, but I thought I'd butt
in here. Lua has simple syntax, which make simple things easy. Lua also has
really extensible semantics, which make complex things possible and more
palatable. The drawback is that the meaning of simple-looking statements can
become hard to decipher. I'm not the most learned person here by far, but
the new semantics of the global statement seem like a step in the right
direction - or at least a lua-like direction. I think it falls into the same
'guru-level' category as some of the more arcane
fallback/tagmethod/metatable uses.

In a general sense, I think the 'global in X' would be used in places like
implementing a class system, a module system, sandboxes, and so on - places
where "heavy wizardry" is already going on. Elsewhere in code it should be
pretty transparent. And that's why I think it's OK.

--James Hearn


Reply | Threaded
Open this post in threaded view
|

Re: global

Peter Loveday-2
> The main issue is whether global declarations as proposed solve the
> perceived need for global declarations.
> --lhf

Well, not having played with it yet (obviously :) I'm not sure if it solves
my problem or not.

The main issue for me, is that I'm using Lua to script an application
where (advanced) end users will be directly writing and modifying Lua
code.  The current problem is that most non-programmers won't really
be aware of the implications, they more or less think along the lines of
"cool I don't have to declare variables in this language"... this leads to
them inadvertantly having all function variables global, and so they
can easily get into variable name conflicts (most people use the same
small set of nams for 'general' variables, like "temp" or "i", "j", "k" etc)
and horrible side-effect possibilities.

Obviously anyone familiar with Lua, or any competant programmer
understands this and can work around it.  What I am looking for
is a way to cut down our tech support to end users for scripting
within our application.  This global variable issue is currently the
biggest potential cause of user confusion.

Does the new system fix this?  I'm not sure; if it means all users
are required to put "global in {}" at the start of every function
then I guess it doesn't really.  Also the fact dofile() doesn't
inherit the 'global scope' of the caller means that function libraries
could have problems too.

I suppose for me the ideal would be an explicit global declaration
and local-by-default behaviour.

Love, Light and Peace,
- Peter Loveday



Reply | Threaded
Open this post in threaded view
|

Re: global

Björn De Meyer
Peter Loveday wrote:
> I suppose for me the ideal would be an explicit global declaration
> and local-by-default behaviour.
> 
> Love, Light and Peace,
> - Peter Loveday

This is much like it is done in PHP, and I also would prefer 
something like this. Variables within function scope should
override variables within global scope. We don't even need a 
seperate keyword, as long as we have a table like 'globals' or 
such in which all global variables are kept.

So for example:

bar = 10;

fuction foo()
bar = 5; -- this bar is local to foo()
print(bar);
bar = globals.bar; 
-- Get your global bar like this.
-- It is ugly, but global variables are 
-- usually a bad idea anyway.
print(bar):   
end;

Should then print: 
5
10

On top of that, a 'global x' keyword could be allowed as
syntactical sugar for 'x = globals.x'.




-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: global

Tomas Guisasola Gorham-2
> > I suppose for me the ideal would be an explicit global declaration
> > and local-by-default behaviour.
> This is much like it is done in PHP, and I also would prefer 
> something like this.
	But in PHP you have access to all functions and (I think)
you can't define a function inside another function...

> On top of that, a 'global x' keyword could be allowed as
> syntactical sugar for 'x = globals.x'.
	But then how would you update the value of 'x'?

	Tomas


Reply | Threaded
Open this post in threaded view
|

Re: global

J. Perkins-2
In reply to this post by Peter Loveday-2
This is the best case for me as well, for the same reasons Peter listed:

 - globals are *very* rare in my system. 99% of the globals that do exist
   are created by the C++ host as a side-effect of loading code packages.
 - I expect a lot of inexperienced coders to use my app (which is why
   I added Lua support to begin with).
 - Bugs resulting from accidental globals are very difficult to find, even
   for experienced coders.

I don't see that the proposed system fixes our problem. I'd be interested
to hear of any alternative solutions, too.

Jason
379



On Friday 19 April 2002 11:16 am, Peter Loveday wrote:
> > The main issue is whether global declarations as proposed solve the
> > perceived need for global declarations.
> > --lhf
>
> Well, not having played with it yet (obviously :) I'm not sure if it solves
> my problem or not.
>
> The main issue for me, is that I'm using Lua to script an application
> where (advanced) end users will be directly writing and modifying Lua
> code.  

(snip)

> I suppose for me the ideal would be an explicit global declaration
> and local-by-default behaviour.

Reply | Threaded
Open this post in threaded view
|

Re: global

Björn De Meyer
"J. Perkins" wrote:
> 
> I don't see that the proposed system fixes our problem. I'd be interested
> to hear of any alternative solutions, too.
> 
> Jason
> 379

I share mostly of your criticism on the "global" statement. With the 
difference that I also use global tables as a data definition method,
and for those, I don't want to have to declare them as global. 
The currently proposed "global" statement is in essence a qualified or
improved "with" statement. But I'm willing to play with the proposed 
"global" and see what it can do for me.

-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: global

Roberto Ierusalimschy
In reply to this post by Thomas Wrensch-2
> My suggestion would be to put out a version (alpha, work, whatever) of
> the language that includes the global declaration and give everyone a
> chance to play with it.

We intend to do that. The problem is that we still do not have a
mechanism to predeclare some functions. Without it, the global mechanism
becomes quite limited.

-- Roberto