[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [CFD] Local functions for Lua 4.1
- From: edrx@... (Eduardo Ochs)
- Date: Thu, 22 Nov 2001 11:54:12 -0200 (BRST)
> 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
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
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,
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...
Eduardo Ochs (who never understood C++, Python or Java),