Re: [CFD] Local functions for Lua 4.1

[edrx@... (Eduardo Ochs)]

> So, what do you think about this proposal?  Discussion opened :-)
>
> Ciao, ET.

I think that the current behaviour is simpler --

  function foo() body end

is just syntactic sugar for

  foo = function() body end

and nothing else. It could be nice to allow things like

  local function foo() body end

but then, to make things consistent,

  local foo, function bar() body end

would have to be translated to

  local foo, bar = function() body end

and that would assign the value `function() body end' to foo, instead
of to bar, and some people would be confused...

In my opinion the best solution is to discipline people to write
things like

  local foo = function() body end

when they are intending to do strange things with the functions that
they create (I can't think of any interesting variation now, sorry). I
like the fact the Lua has *NO* function declarations, only function
values, that are assigned to variables; and a function value is a
pointer to a sequence of bytes stored somewhere, that contains the
bytecode for the function, and that sequence of bytes can even be
garbage-collected when nothing else references it -- just like strings
or tables.

Lua is the most elegant language that I've stumbled on in many years,
and it is by far the simplest to learn and to use; I would like to
keep it that way.

BTW, here is what I think that we should be dreaming of -- in the long
term, of course -- instead of other rules of scope:

  1) Nice drawings of the Lua datatypes so that more people could
     readily grasp the details of what Lua "really" does. My canonical
     examples of what are good drawings of this type always come from
     the Emacs Lisp manual: for example,
       <http://angg.twu.net/info2www.cgi?(elisp)Lists+as+Boxes> and
       <http://angg.twu.net/info2www.cgi?(elisp)Cons+Cell+Type>.

  2) Another Lua parser, written in Yacc or in Lua, and possibly much
     slower than the default one, that people could change more easily.

  3) Small changes to the standard parser to let people replace parts
     of it -- like the code that says how it converts, say, a
     "function foo() body end" construct to bytecode -- on the fly.

I think that (3) is much in the Lua spirit -- the default Lua parser
would become a meta-mechanism for implementing similar languages with
slightly different rules of scope... and it starts in a state that is
simple and quite convenient for writing small programs...

  Buenas salenas,
    Eduardo Ochs   (who never understood C++, Python or Java),
    http://angg.twu.net/
    http://www.mat.puc-rio.br/~edrx/
    edrx@inx.com.br