[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [CFD] Local functions for Lua 4.1
- From: RLake@...
- Date: Thu, 22 Nov 2001 09:59:55 -0500
Edgar Toernig escribió:
>> Nonetheless, I don't like the idea of having one default for function
>> different default for variables.
> There's no difference. The local-statement introduces a new local as
> the for-statement or the new definition of the function-statement. It
> tries to give a more sensible semantic to the "syntactic sugar" of the
> function-statement (that it introduces a new local).
I don't think that's quite accurate, unless you intend that global
functions *always* need to be flagged as global using what I consider to be
an ugly syntax. (function global.foo ...) (but that's just one person's
opinion.) Otherwise, every function would be chunk-local, which is probably
not intuitive either.
>> local function f(args) body
> I thought about that too. But I prefer the local to be implicit. You
> want to write "for local i=1,100 do..." either ;-)
Actually, I wouldn't mind if there was an alternative. I would actually be
like to use local in while loops sometimes, but I can't think of a good
syntax since assignment is not an operator (and I usually approve of that
As I mentioned in some earlier posting, I don't actually like the 4.1alpha
for i = 1, 100 do ... end
which is more or less equivalent to
begin local i = 1
while i <= 100 do ... i = i+1 end
with the consequence that if I want to create a closure with the index
variable I need to say
for i = 1, 100 do local i = i ... end
In this particular case, I'd be happier being able to say
for local i = 1, 100 do ... end
which would be easier to read (and type).
On the other hand, I'd be just as happy if the semantics of a for-loop were
changed with respect to the scope of a local.
Mientras tanto, Eduardo Ochs escribió:
> 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...
Well, some people are going to be confused no matter what :-) I get
confused a lot, myself.
However, the definition I proposed of local function f(args) body end was
local f = function (args) body end
f = function(args) body end
for the reasons explained by Edgar.
I failed to mention in my original proposal that I would actually like the
syntax to be something like:
local function f(args1) body1 end , function g(args2) body2 end ...
to be equivalent to:
local f, g
f = function(args1) body1 end
g = function(args2) body2 end
which would handle mutual recursion properly (unlike Edgar's proposal,
which wouldn't). However, I accept that this is both inconsistent (with,
for example, local a,b = b,a)
and subtle (the comma could easily be ignored in the absence of good
margins and syntax colouring.)
This is the letrec of Scheme-like languages, but the word "letrec" has
always struck me as opaque. It could be that a better syntax would be:
local functions f(args1) body1 end, g(args2) body2 end
localfunctions f(args1) body1 end, g(args2) body2 end
but that's creeping keyword-ism.
This is not a formal proposal, you understand. Just random thoughts to
hopefully contribute to the debate.