Re: about the next version

[Edgar Toernig <froese@...>]

Roberto Ierusalimschy wrote:
> 
> > But the 'global ... in <table>' is something completely different.  It doesn't
> > address the mentioned 'need'.  It introduces a method for complicated dynamic
> > variable bindings and my fear is that you get even more complex rules (Which
> > identifier accesses which object?) than the rules in C++.  Reading sources
> > may become a nightmare.
> 
> I did not understand your point. The binding rules seem quite simple to me:
> 
> 1) look for an explicit declaration for that variable, using the usual
> scope rules.
> 
> 2) if there is no explicit declaration, look for the inner default
> declaration.
> 
> 3) if there are no default declarations, the variable is a "free" global.

The scope rules (which define which declaration to take for a name) are
not what I meant (although there are some subtleties, too - see below).
I meant the dynamic binding of a name (which storage location is accessed
by that name).  [My comparison with C++ was bad - it has complex scope rules.]

Sure, with 'old' globals table you could play tricks too (redirecting
names to different tables, generate calculated values, etc).  But that
was considered to be some special heavy magic.  The 'global in <table>'
is different.  The simple form (i.e. global in T) is normally not enough.
You need some symbols from other tables.  So I think that what you'll
normally find is something like 'global in <function>' where a function
will create a table to be used (see my dictionary example some posts ago
or Peter's try to use if for C++-like field access).  And suddenly you no
longer know what you'll access with a 'global variable'.  It becomes a
run-time decision.

About the scope rules: the fact that 'precise declarations' (global <name>)
take precedence over 'default declarations' (global in <table>) can create
strange situations.  A block of code that works well in one context no
longer works in a different one.  I.e. you can't cut'n'paste a function
from one file to another if it uses 'default declarations'.  You have
to copy the required 'precise declarations' too or you may get hard to
find bugs.

And then, as far as I understand it, 'default declarations' do not nest
in the sense that all of them are used for the binding.  Only the inner-
most one is taken.  That gives some kind of 'undefining' a global within
a block.

Ciao, ET.