lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 15/06/2011 19.29, Roberto Ierusalimschy wrote:

[snip]


This time, however, we would like feedback about the syntax for labels,
because of the small incompatibility of the '@' with filenames.  (Note
that "local name" and anything similar that mixes gotos with variables
is not a *syntax* for labels and is completely out of our plans.)

Some real contenders:

1) keep all as it is
2) change the indication of filenames in debug info and in LUA_INIT
3) ::label::
4) |name|
5)&name:
6) !name:
::label:: is best for me: symmetric (marks a point in code); bulky (stands out by itself); comparatively easy to type (minor point, I admit); it helps "label" stand out; doesn't clash too much with operators in other languages (avoids mental interference: & recalls "and" from C, |name| may also be confounded with abs in math).
A point worth underlining about bulkiness and symmetry: how does it look like when the code is _not_ pretty printed? Maybe it is a bad 
practice, but since Lua is free form...
Moreover sometimes it is useful to pack a couple or more Lua lines in a command line. 

Compare:
... do return 0 end ::error1:: print("error 1!") do return 1 end ::error2:: print("error 2!") do return 2 end ...
... do return 0 end @error1: print("error 1!") do return 1 end @error2: print("error 2!") do return 2 end ...
... do return 0 end |error1| print("error 1!") do return 1 end |error2| print("error 2!") do return 2 end ... 


IMHO the first case is more readable (YMMV).
Additionally I suggest adding the constraints that the label cannot contain spaces, to avoid badly readable code: 

:: label::  -- error!
::    label    :: --error!
The "::label::" syntax helps in this case too, since it doesn't hamper the readability of the label, and so reduces the need of additional spaces around it (whose only sensible use would be for readability's sake). 



we are also considering to enforce a single occurence of a label name in
each function, to avoid ambiguities. (That does not change the visbility
rules; it is only an extra restriction.)



Maybe too constraining for some complex error management.
Why not a limit "per-block"?

So I could write:

do
  ....
  ::error1::
  ....
  ::error2::

end

do
  ....
  ::error1::
  ....
  ::error2::

end

but not:

do
  ....
  ::error1::
  ....
  ::error2::
  ....
  ::error1::
  ....
end
The latter is probably a mistake, the former may be used a uniform error naming strategy inside a long function body, without forcing one to create unnecessary closures to reuse label names or choose slightly different label names each time. 





Of course we need feedback on the rest of the stuff, too!

-- Roberto