[ANNOUNCE], assembler for the Lua VM (4.1-alpha) ;-)

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

[ANNOUNCE], assembler for the Lua VM (4.1-alpha) ;-)

luagnom
Hi,

For thoses who likes weird things, I am pleased to share with you 'luas', a assembler for the Lua virtual machine (only for lua-4.1-alpha). 
Download at : <http://luagnome.free.fr/pub/luas010828.tar.bz2> (see README and syntax.html in the distribution).

Have fun!

Reply | Threaded
Open this post in threaded view
|

Down with Upvalues

John D. Ramsdell-3
Some of the postings on lua-user.org demonstrate that upvalues are
very confusing.  They confuse some people so much that they think the
current version of Lua is lexically scoped!  Let's get some basics
straight. 

Lua is a statically scoped language in which each variable has either
local or global scope.  Functions can be defined within functions,
however, a nested function does not have access to variables defined
in any of its enclosing functions.  Therefore, Lua is not lexically
scoped.  Thus, the following Lua code is illegal:

function addn(x)
  function sum(y)
    return x+y
  end
  return sum
end
print((addn(3))(1))

This example is illegal because variable x defined in addn is
inaccessible to the sum nested function.

Nested functions can get access to a copy of a variable defined in its
immediately enclosing function.  An upvalue reference to a variable
within a function extracts this copy when the function is evaluated to
produce a closure.  A variable reference preceded by a percent sign
signifies an upvalue reference.  Placing a percent sign in front of
the x reference in sum makes the above example legal Lua code.

This poor substitute for lexical scoping has been adopted because it
makes it easy to produce an implementation in which all non-global
variables are stack allocated, however, one need not give up lexical
scoping to have stack allocated non-globals.

The Python language previous to version 2.2 had scoping rules similar
to Lua's current rules--each variable had either local or global scope.
As of version 2.2, Python is lexically scoped, or in their terms,
non-global variables have static nested scope.

In Python's implementation, non-global variables referenced from a
nested function are immutable.  With this extra assumption, stack
allocated non-globals is easily implemented.  

Python's implementation demonstrates the validity of this approach.
They have a fast implementation as a result of using flat closures, as
described in 1984 by Luca Cardelli in a paper called "Compiling a
Functional Language".

  http://citeseer.nj.nec.com/cardelli84compiling.html

The relevant section is 4 on "Fetching variables".

For those of us who hope that future versions of Lua will be lexically
scoped, I suggest we can help by finding implementation techniques
that can be used by the core Lua implementors.  I think we should
carefully study the relevant sections of the Python 2.2 implementation
for ideas, and make them available.  Suggesting Lua is lexically
scoped when it is not, is counter productive.

I believe programs written in a good very high-level language should
be easily read by people only casually familiar with the language.
With the exception of upvalues, I think Lua excels in this respect as
it adopts Pascal-like syntax for control structures whose meaning is
just what one would expect.  Programs that employ upvalues are
unlikely to be understood by casual users.  One needs a manual to
understand when they get their value.  Most people intuitively
understand lexical scoping.  Making variables immutable when they are
referenced from within a nested function puts a burden on the authors
of a Lua program, but not on readers of the program.  I think Lua
should be designed to meet the needs of readers foremost.

John

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Edgar Toernig
ping "John D. Ramsdell" wrote:
> 
> Some of the postings on lua-user.org demonstrate that upvalues are
> very confusing.  They confuse some people so much that they think the
> current version of Lua is lexically scoped!  Let's get some basics
> straight.
> 
> Lua is a statically scoped language in which each variable has either
> local or global scope.

Yeah.  Let's get it straight :-)

I think the confusion is on your side because you make a distinction
between lexical and static scoping.  It's the same.  If you think
I'm wrong give a reference to a text that defines the difference.
By your understanding C (or GCC if you require function nesting) is
not lexically scoped either and a lot of people will disagree.

> Functions can be defined within functions,
> however, a nested function does not have access to variables defined
> in any of its enclosing functions.  Therefore, Lua is not lexically
> scoped.

You are focused very much on function nesting.  There are more kind of
nesting constructs in Lua (for-do-end, while-end, do-end, ...).  Just
because some scope accesses are forbidden/unsupported does not mean
that it's not lexically scoped.  What if i.e. Pascal had a "private"
keyword for locals which prohibits access from other functions.  Would
this make Pascal no longer lexically scoped?

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

John D. Ramsdell-3
Edgar Toernig <[hidden email]> writes:

> I think the confusion is on your side because you make a distinction
> between lexical and static scoping.  It's the same.  If you think
> I'm wrong give a reference to a text that defines the difference.

I got to run, and am taking some time off, but I'll get back to you on
this.  I believe the pointer on lua-user.org fully explains the
concept of lexical scoping.  It's not the opposite of dynamic scoping,
did you notice?

> By your understanding C (or GCC if you require function nesting) is
> not lexically scoped either and a lot of people will disagree.

As I understand C, every nested function it allows has access to all
variables in all enclosing functions in which it exists, therefore, C
is lexically scoped.  C is a boring example of a lexically scoped
language because it meets the nested function test by prohibiting them.

> > Functions can be defined within functions, however, a nested
> > function does not have access to variables defined in any of its
> > enclosing functions.  Therefore, Lua is not lexically scoped.

> You are focused very much on function nesting.  There are more kind
> of nesting constructs in Lua (for-do-end, while-end, do-end, ...).
> Just because some scope accesses are forbidden/unsupported does not
> mean that it's not lexically scoped.  What if i.e. Pascal had a
> "private" keyword for locals which prohibits access from other
> functions.  Would this make Pascal no longer lexically scoped?

The point to focus on is that if a language fails the nested function
test, it's not lexically scoped.  There is no need to consider other
issues.

So long.

John

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Edgar Toernig
"John D. Ramsdell" wrote:
> 
> Edgar Toernig <[hidden email]> writes:
> 
> > I think the confusion is on your side because you make a distinction
> > between lexical and static scoping.  It's the same.  If you think
> > I'm wrong give a reference to a text that defines the difference.
> 
> I got to run, and am taking some time off, but I'll get back to you on
> this.  I believe the pointer on lua-user.org fully explains the
> concept of lexical scoping.  It's not the opposite of dynamic scoping,
> did you notice?

Well, lexical and dynamic scope are the two basic scoping rules.
Not opposing rules but two sets that can exist together.

To the lua-user.org pointer.  You wrote:

   "In a static language, all variable references can be resolved at
   compile time. In a lexically scoped language, nested functions have
   access to variables defined in their enclosing functions."

A lot of formal text books I read does not even mention functions when
defining lexical/static and dynamic scoping.  They use the term "scope"
or "block".  The most formal ones even omit the "most closely nested"
rule when defining lexical scoping and only say that this is an often
found addition.  And I've yet to see a book that makes a difference
between lexical and static scope.

> C is a boring example of a lexically scoped language because it meets 
> the nested function test by prohibiting them.
>[...]
> The point to focus on is that if a language fails the nested function
> test, it's not lexically scoped.  There is no need to consider other
> issues.

I think that this a pretty personal and unique requirement.  It would
mean that if I prohibit nested function definitions in Lua[1] it would
become "lexically" scoped without changing any scoping rules![2]

Ciao, ET.

[1] Just insert this line at lparser.c:body:1095:
  check_condition(ls, ls->fs->prev == NULL, "function nesting prohibited");

[2] Sounds like "If a car has a stereo it must have min 2x50W else it's
    no longer a car." ;-)

Reply | Threaded
Open this post in threaded view
|

Lexical scope definition

Jonathan  Branam
I should probably stay out of this, but it is too tempting. Unfortunately I
don't know what book is considered the "Bible of Programming Languages" or I
would check it. However, I have always heard lexical scope definied the same
way (until now).

Lexical scope: The scope of an identifier can be determined by a lexical
analysis of the block of code.

Normally this description is also followed by other statements such as: This
can be determined at compile time and is therefore more efficient. This
constrasts with dynamic scoping in which the the scope of an identifier can
only be determined at run-time.

-Jonathan

PS: I do not claim that the internet is a good place to go for information
of this kind, as it contains lots of misinformation as well. But at least it
usually gives you a sense of what the "popular" opinion is. In any case,
almost every reference I found supports this definition. However, several do
attempt to add more to it. Such as the requirement that identifier scope can
reach up through the function tree (I mean, that you can access identifiers
from enclosing functions always).

http://www.xanalys.com/software_tools/reference/HyperSpec/Body/glo_l.html
lexical scope n. scope that is limited to a spatial or textual region within
the establishing form. ``The names of parameters to a function normally are
lexically scoped.''

http://ase.isu.edu/ase01_07/ase01_07/bookcase/ref_sh/foldoc/14/62.htm
lexical scope
<programming> (Or "static scope") In a lexically scoped language, the scope
of an identifier is fixed at compile-time to be the smallest block
(begin/end or function/procedure body) containing the identifier's
declaration. This means that an identifier declared in some block is only
accessible within that block and from procedures declared within it.
Opposite of dynamic scope. See activation record.

http://www.cs.utexas.edu/users/wilson/schintro/schintro_53.html
Scheme uses a lexical scope rule. (We can also say that Scheme is statically
scoped, rather than dynamically scoped, like some old Lisps.) When you see a
variable name in the code, you can tell what variable it refers just to by
looking at the source code for the program. A program consists of possibly
nested blocks of code, and the meaning of the name is determined by which
variable binding constructs it's used inside.

http://courses.cs.vt.edu/~cs3304/Spring00/notes/Chapter-4/tsld025.htm
Static (Lexical) Scope
Based on program text
To connect a name reference to a variable, you (or the compiler) must find
the declaration
Search process: search declarations, first locally, then in increasingly
larger enclosing scopes, until one is found for the given name
Enclosing static scopes (to a specific scope) are called its static
ancestors; the nearest static ancestor is called a static parent

http://ilusion.inesc.pt/~tl/clm/node43.html
Lexical scope. Here references to the established entity can occur only
within certain program portions that are lexically (that is, textually)
contained within the establishing construct. Typically the construct will
have a part designated the body, and the scope of all entities established
will be (or include) the body.
Example: the names of parameters to a function normally are lexically
scoped.

http://perl.about.com/library/weekly/aa022101b.htm
What is lexical scope?
my variables are said to have lexical scope, which means that variables are
defined for the block they are in, and they are not generally visible to
subroutines. There are exceptions, and I'll tell you about those later in
this feature. To use my, simply put it in front of your variable name when
you declare it, like this:
my $variable;
Perl will create space for a private variable named $variable, visible only
within the block of code that defines it. The variable is used while within
the block, and Perl gets rid of it when its done with the block.




Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

John D. Ramsdell-3
In reply to this post by Edgar Toernig
Edgar Toernig <[hidden email]> writes:

> Well, lexical and dynamic scope are the two basic scoping rules.
> Not opposing rules but two sets that can exist together.

Are you asking if a language can have both lexically scoped and
dynamically scoped variables at the same time?  Yes, this is true, but
a language that allows some dynamic variables is not considered to be
static or lexically scoped.

> To the lua-user.org pointer.  You wrote:
> 
>    "In a static language, all variable references can be resolved at
>    compile time. In a lexically scoped language, nested functions have
>    access to variables defined in their enclosing functions."
> 
> A lot of formal text books I read does not even mention functions when
> defining lexical/static and dynamic scoping.  They use the term "scope"
> or "block".  The most formal ones even omit the "most closely nested"
> rule when defining lexical scoping and only say that this is an often
> found addition.  And I've yet to see a book that makes a difference
> between lexical and static scope.

The rule I sited about nested functions is a consequence of the usual
definition of lexical scoping.  Here is the definition I found at
http://lua.swiki.net/13 on July 27th:

   In a lexically scoped language, the scope of an identifier is fixed
   at compile-time to be the smallest block (begin/end or
   function/procedure body) containing the identifier's
   declaration. This means that an identifier declared in some block
   is only accessible within that block and from procedures declared
   within it.

That link is no longer accessible from that page, but if you know it,
I would greatly appreciate it if you would send it to me.

As I scan some of the links I have found, I notice that when they
equate lexical scoping with static scoping, they also define lexical
scoping as above.  I can only conclude that if you believe there is
no difference between lexical and static scoping, than you must
conclude that Lua is not statically scoped.

> > C is a boring example of a lexically scoped language because it meets 
> > the nested function test by prohibiting them.
> >[...]
> > The point to focus on is that if a language fails the nested function
> > test, it's not lexically scoped.  There is no need to consider other
> > issues.
> 
> I think that this a pretty personal and unique requirement.  It would
> mean that if I prohibit nested function definitions in Lua[1] it would
> become "lexically" scoped without changing any scoping rules![2]

This is correct.  The situation is more interesting.  If you prohibit
all local variables including function parameters, than Lua would also
be lexically scoped.  The lack of nested scoping in the presence of
nested functions is why Lua is not lexically scoped.

On another subject, can we agree that Lua variables do not have nested
scope? 

John

Reply | Threaded
Open this post in threaded view
|

Re: Lexical scope definition

John D. Ramsdell-3
In reply to this post by Jonathan Branam
Jonathan,

Thank you for finding many references that support my notion of
lexical scoping.  Thank you also for finding the particular definition
I was looking for.  Notice that by this definition, Lua is not
statically scoped.

John

"Jonathan  Branam" <[hidden email]> writes:

> http://ase.isu.edu/ase01_07/ase01_07/bookcase/ref_sh/foldoc/14/62.htm
> lexical scope
> <programming> (Or "static scope") In a lexically scoped language, the scope
> of an identifier is fixed at compile-time to be the smallest block
> (begin/end or function/procedure body) containing the identifier's
> declaration. This means that an identifier declared in some block is only
> accessible within that block and from procedures declared within it.
> Opposite of dynamic scope. See activation record.

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Adolf Mathias
In reply to this post by John D. Ramsdell-3
"John D. Ramsdell" wrote:
> 
> Edgar Toernig <[hidden email]> writes:
> 
> > Well, lexical and dynamic scope are the two basic scoping rules.
> > Not opposing rules but two sets that can exist together.
> 
> Are you asking if a language can have both lexically scoped and
> dynamically scoped variables at the same time?  Yes, this is true, but
> a language that allows some dynamic variables is not considered to be
> static or lexically scoped.

I would vote that such a language is both. Consider fluid-let in some
Schemes which does dynamic binding as opposed to the static bindings
created by let... and lambda, e.g.:

(define stdout (current-output-port))

(define (wrstdout x) (write x stdout))

(fluid-let ((stdout (open-output-file "redirected-output"))) (wrstdout
"Hello World"))

I'd say it's not so much a question of the language but of the
variables. One is lexically bound and the other is dynamically bound.


Dolfi

-- 
Adolf Mathias              EMail: dolfi at zkm dot de  Web: www.zkm.de
|||| / |< |||                 ZKM Basic Research - Grundlagenforschung
P.B. 6919 D-76049 Karlsruhe, Germany; fon +49 721-8100-1511, fax -1509

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Jay Carlson
In reply to this post by John D. Ramsdell-3
> Are you asking if a language can have both lexically scoped and
> dynamically scoped variables at the same time?  Yes, this is true, but
> a language that allows some dynamic variables is not considered to be
> static or lexically scoped.

I don't buy this.  I'm thinking of Oaklisp, which had fluid-let and (fluid
variablename) locatives.  Does Oaklisp lose its lexical-scoping-nature
because of the fluid stuff, which is clearly an add-on after the fact?  (I
believe it was implemented in terms of dynamic-wind.)

Jay


Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

John D. Ramsdell-3
"Jay Carlson" <[hidden email]> writes:

> > Are you asking if a language can have both lexically scoped and
> > dynamically scoped variables at the same time?  Yes, this is true, but
> > a language that allows some dynamic variables is not considered to be
> > static or lexically scoped.
> 
> I don't buy this.  I'm thinking of Oaklisp, which had fluid-let and (fluid
> variablename) locatives.  Does Oaklisp lose its lexical-scoping-nature
> because of the fluid stuff, which is clearly an add-on after the fact?  (I
> believe it was implemented in terms of dynamic-wind.)

I don't have a strong opinion on this, so whatever.

John

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Nick Trout-2
In reply to this post by Jay Carlson
----- Original Message ----- 
From: "Jay Carlson" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Thursday, August 30, 2001 2:07 PM
Subject: Re: Down with Upvalues


| > Are you asking if a language can have both lexically scoped and
| > dynamically scoped variables at the same time?  Yes, this is true, but
| > a language that allows some dynamic variables is not considered to be
| > static or lexically scoped.
| 
| I don't buy this.  I'm thinking of Oaklisp, which had fluid-let and (fluid
| variablename) locatives.  Does Oaklisp lose its lexical-scoping-nature
| because of the fluid stuff, which is clearly an add-on after the fact?  (I
| believe it was implemented in terms of dynamic-wind.)


dynamic-wind ??

8^D




Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Edgar Toernig
In reply to this post by John D. Ramsdell-3
"John D. Ramsdell" wrote:
>
> On another subject, can we agree that Lua variables do not have nested
> scope?

He?  Of course they have nested scope.  Or how would you call this?

  i="level0"
  do
    local i="level1"
    while foo do
      local i="level2"
      if bar then
        local i="level3"
        function baz()
          local i="level4"
          print i -- level4
        end
        print i -- level3
      else
        print i -- level2
      end
      print i -- level2
    end
    print i -- level1
  end
  print i -- level0

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: Lexical scope definition

Edgar Toernig
In reply to this post by John D. Ramsdell-3
"John D. Ramsdell" wrote:
> 
> "Jonathan  Branam" <[hidden email]> writes:
> 
> > http://ase.isu.edu/ase01_07/ase01_07/bookcase/ref_sh/foldoc/14/62.htm
> > lexical scope
> > <programming> (Or "static scope") In a lexically scoped language, the scope
> > of an identifier is fixed at compile-time to be the smallest block
> > (begin/end or function/procedure body) containing the identifier's
> > declaration. This means that an identifier declared in some block is only
> > accessible within that block and from procedures declared within it.
> > Opposite of dynamic scope. See activation record.
> 
> Thank you for finding many references that support my notion of
> lexical scoping.  Thank you also for finding the particular definition
> I was looking for.  Notice that by this definition, Lua is not
> statically scoped.

First, this definition makes no distinction between lexical and static
scope.

Then, this definition takes more constraints on the lexical scope then
most other definitions - it makes the "most closely nested" rule a
requirement.  It excludes all languages that do not use this rule.
What are these languages?  Neither dynamic nor lexical or static.  Not
scoped at all?!?

Further: It says "...only accessible within that block and from procedures
within it."  Maybe it would be better to say "visible" than "accessible"[1].
And in Lua variables are visible from nested functions - only the access
to them is forbidden.

And last: this is from "The Free On-Line Dictionary of Computing" compiled
by hundreds of contributors.  It's hardly a normative reference; especially
this entry has more the nature of a glossary entry.  I guess, if I would
made a more formal chapter about lexical scoping it would be added. ;-)

Ciao, ET.


[1] the wording is a little bit vague anyway: it would not allow nested
blocks to access a variable.  Lua would not even have blocks because
they are not made with "begin/end".  ;-)  And functions are not allowed
either, only procedures...

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

John D. Ramsdell-3
In reply to this post by Edgar Toernig
Edgar Toernig <[hidden email]> writes:

> He?  Of course they have nested scope.  Or how would you call this?

Your example show code that demonstrates nested scoping, but the
following code shows that Lua variables lack nested scope.

1.     function addn(x)
2.       function sum(y)
3.         return x+y      -- illegal reference to x
4.       end
5.       return sum
6.     end
7.     print((addn(3))(1))

If the variable x had nested scope, the scope of variable x would be
delimited by the function/end keyword pair.  It would start at line 2,
and continue until line 5.  With nested scoping, the reference to
varible x on line 3 would be legal.

Lua variables have either global or local scope.  A locally scoped
variable is accessible only within the function in which it is
defined.  Variable x is defined in addn, so its scope is not delimited
by the function/end keyword pair.  All regions that define a nested
function are removed from its scope.

In summary, the existence of local scoping and nested functions means
that Lua lacks nested scoping.

John

Reply | Threaded
Open this post in threaded view
|

Re: Lexical scope definition

John D. Ramsdell-3
In reply to this post by Edgar Toernig
Edgar Toernig <[hidden email]> writes:

> First, this definition makes no distinction between lexical and static
> scope.

Which implies that Lua is not statically scoped either.  Several of
the definitions imply this.  I note that the Python community use the
term "static nested scoping", suggesting that a language can have
static scoping, but not nested scoping.  For them, it appears that
static nested scoping means the same thing as lexical scoping.  I'm
not sure what static scoping means to them.

John

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Edgar Toernig
In reply to this post by John D. Ramsdell-3
"John D. Ramsdell" wrote:
> 
> Your example show code that demonstrates nested scoping, but the
> following code shows that Lua variables lack nested scope.
> 
> 1.     function addn(x)
> 2.       function sum(y)
> 3.         return x+y      -- illegal reference to x
> 4.       end
> 5.       return sum
> 6.     end
> 7.     print((addn(3))(1))
> 
> If the variable x had nested scope, the scope of variable x would be
> delimited by the function/end keyword pair.  It would start at line 2,
> and continue until line 5.  With nested scoping, the reference to
> varible x on line 3 would be legal.

You mix scope with accessibility.  The scope of x starts at line 1
and ends at line 6.  You get a compile time error just because Lua
has nested lexical scope.  When seeing the use of the variable x in
line 3 the compiler decides (based on nested lexical scope rules)
that the declaration of x in line 1 has to be taken.  But because
this access is not allowed in current implementation it issues an
error message.  If Lua hadn't nested scope the compiler would most
likely have chosen some other declaration of x (i.e. global x or an
implied declaration of x local to sum) and would not have issued an
error message.

Over and out, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

John D. Ramsdell-3
> You mix scope with accessibility.

...

Edgar,

The purpose of scoping rules is to define accessibility.
Look at the FOLDOC definition of lexical scoping.

     In a lexically scoped language, the scope of an identifier is
     fixed at compile-time to be the smallest block (begin/end or
     function/procedure body) containing the identifier's
     declaration. This means that an identifier declared in some block
     is only accessible within that block and from procedures declared
     within it.

It defines lexical scoping by describing when and were a variable is
accessible.  Accessibility is what scoping is all about.

John

Edgar Toernig <[hidden email]> writes:

> "John D. Ramsdell" wrote:
> > 
> > Your example show code that demonstrates nested scoping, but the
> > following code shows that Lua variables lack nested scope.
> > 
> > 1.     function addn(x)
> > 2.       function sum(y)
> > 3.         return x+y      -- illegal reference to x
> > 4.       end
> > 5.       return sum
> > 6.     end
> > 7.     print((addn(3))(1))
> > 
> > If the variable x had nested scope, the scope of variable x would be
> > delimited by the function/end keyword pair.  It would start at line 2,
> > and continue until line 5.  With nested scoping, the reference to
> > varible x on line 3 would be legal.
> 
> You mix scope with accessibility.  The scope of x starts at line 1
> and ends at line 6.  You get a compile time error just because Lua
> has nested lexical scope.  When seeing the use of the variable x in
> line 3 the compiler decides (based on nested lexical scope rules)
> that the declaration of x in line 1 has to be taken.  But because
> this access is not allowed in current implementation it issues an
> error message.  If Lua hadn't nested scope the compiler would most
> likely have chosen some other declaration of x (i.e. global x or an
> implied declaration of x local to sum) and would not have issued an
> error message.
> 
> Over and out, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Lexical scope definition

John D. Ramsdell-3
In reply to this post by Jonathan Branam
In the interest of full disclosure, I should tell you that I have been
a Scheme user since the early 1980s.  I participated in the Scheme
standardization efforts, as a member of the group that produced the
RnRS series, and as a member of the Scheme Working Group of the
Microprocessor and Microcomputer Standards Subcommittee that produced
the IEEE Standard for the Scheme Programming Language.

Scheme was the first major Lisp dialect that combined lexical scoping,
first-class procedures, and dynamic typing.  Compilers for Scheme
demonstrated that lexically scoped dialects of Lisp can be efficiently
implemented.  I participated in many discussions on the nature of
lexical scoping.

Let me make it clear that any definition of lexical scoping taken from
a Scheme source will further my case.  In the eighties, general
agreement was found.  The Scheme reference on

  http://lua-users.org/wiki/LuaScopingDiscussion 

is

  http://www.htdp.org/2001-01-18/Book/node104.htm

a classic example of a link that furthers my cause.

John

Reply | Threaded
Open this post in threaded view
|

Re: Down with Upvalues

Russell Y. Webb
In reply to this post by John D. Ramsdell-3
As I understand it, the issue is what are the ideal or desired scoping rules
for Lua?  It seems that there is a lot of debate about terminology, but
little disagreement about what would be ideal.

I have yet to see a coherent argument stating that upvalues are anything
other than a compromise or claiming that they are fun or even clear.  Every
one seems to agree that in an ideal world the compiler would do the obvious
scoping based on the source and not the runtime state --- that fits with how
globals work today and extending an accepted idea seems clear.

So a more uniform scoping rule that is an extension of the rules for globals
today seems to the on the wish list for Lua.  It's up to the Lua authors to
consider what to do with the language and up to us to help by making
implementation suggestions (or even complete implementations) if it's
important.

What is really under debate?  Hopefully not vocabulary...

Perhaps I've missed a serious issue about the future possibilities of the
language to debate.  If so, it may help lots of people on the list to
clarify what that issue is.

In any case, it would be useful to know if basically we all agree on what
would be ideal aside from how it could be accomplished or what compromises
it entails. 

Russ



123