Re: [CFD] Local functions for Lua 4.1

[RLake@...]

Edgar Toernig escribió:

>>
>> Nonetheless, I don't like the idea of having one default for function
and a
>> different default for variables.

> There's no difference.  The local-statement introduces a new local as
does
> the for-statement or the new definition of the function-statement.  It
only
> 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
don't
> 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
choice).

As I mentioned in some earlier posting, I don't actually like the 4.1alpha
version of

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
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
not:

local f = function (args) body end

but rather

local f
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

or even

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.

Rici