Re: upvalues: doc suggestions and another opinion

[Luiz Henrique de Figueiredo <lhf@...>]

>From: Edgar Toernig <froese@gmx.de>
>Date: Fri, 21 Apr 2000 22:57:50 -0300 (EST)

>Here I some things I would like to find a cleaner solution for:

>5) local x do local y function z(...)  ... %x ... %y ... end end
>
>   That is, allow access to all upper scopes.

This already works as you want.
It seems that there is some confusion regarding what can be used as an upvalue.
The rule in the manual is

	The name used in an upvalue may be the name of any variable visible
	at the point where the function is defined.

This means that global variables and the local variables in *all* enclosing
functions can be used. Local variables in the function being defined are not
allowed as upvalues simply because something like
	local a
	...
	x=%a
is probably a typo, because x=a would be the natural thing to do.
For the same reason, upvalues cannot be used in the main part of a chunk.
Accordingly, the only two parse errors regarding upvalues are
	cannot access upvalue in main
	cannot access an upvalue in current scope

>It's pretty hard to find clean solutions for these things if a
>simple table and the current upvalue mechanism suffices.

Right. To keep it simple (and upvalues are already a somewaht complex notion),
we prefer not to add more syntax for the things you mentioned, given that
you can always use a table value as an upvalue and then *update* the fields
in this table. In other words, the upvalue itself is read-only, in the sense
that its value cannot be changed, but the fields of the table are writable and
persistant.

On the other hand, I would like to have a clean solution for the constructs
below, but these are special cases (ie, recursive functions), and the effort
and added complexity do not seem worth it.

>1) local f = function(...) ... %f ... end
>2) local f  function f(...)  ... %f ... end

--lhf