Re: Lua 4.0 (alpha) now available

[Bennett Todd <bet@...>]

2000-05-03-20:36:46 Edgar Toernig:
> [ auto-local iterator variables on for loops ]
> Up to now the rules were: Every undeclared variable is a global.  If you
> want locals you have to define them.  Now you have the extension: unless
> it's the iteration var of a for loop, then it's always a local only visible
> within the body of the for-loop.  And if you think that consistency has
> a higher priority then niceness it looks wrong *g*

On the other hand, iterator variables for loops are fundamentally
different from other variables; they have a special meaning being
associated with them by the loop construct itself. This meaning only
applies within the scope of the loop. So to revisit your example:

      n="foo"                         -- global n
      print(n)                        -- foo
      for n=1,3 do print(n) end       -- 1 2 3
      print(n)                        -- foo

would you have that last instance print "3" or "4"? Either way it's
a side-effect of a detail of the internal implementation of the for
loop. I'd be much rather have it print "foo", myself. Unlike the
iterator variable, that's an assignment I've done myself.

> But labeled breaks are a nuisance.  First you have to invent silly
> names (L1,L2,L3).

Well, if you _want_ to give them silly names, you're welcome to do
so of course, just like you're welcome to use the same variable name
as a persistent global as the name of an iterator variable. That
doesn't make it good style. Do you have an objection to giving your
blocks reasonable names? I don't know the syntax proposed for the
Lua labeled block break, but the equivalent construct in perl I use
all the time:

	file: for my $file (@ARGV) {
		open FP, "<$file" or die;
		line: while (<FP>) {
			...
			last line if /done/;
			...
			last file if /abort/;
		}
	}

and I don't have to worry about whether that invocation is in an
additional nesting. If you take the effort to label the blocks to
describe the objects they are manipulating, labelled block
restarters or exits become quite clear and helpful. Far better than
"break 1" which needs to become "break 2" if you insert another
level of block nesting to handle some other iteration or testing or
whatever.

> Then you don't know where to write them (indented, left flushed,
> ...)

I purely do not understand the point you're trying to make here.
Pick a style and stick to it. A lot of people like out-denting block
labels a few spaces, to make 'em hang out a bit. I'm quite happy
just putting the label where I'd put the beginning of the unlabelled
block.

> and at last, if you see some "break foo" you have to search for
> this damned label to see what loop you leave.

So use "break line" to exit the block that's looping once per line,
"break file" to exit the block that's looping once per file, etc. If
you use meaningless names then you can reduce the construct to the
point where it's as cryptic as numbered blocks, although still not
as fragile.

> A "break 2" gives you a direct context, and you don't have to
> invent a label-syntax.

It tells you to go out two blocks. How far out as that? Is it as
easy to search for as a string search in your text editor? And can
it ever be as self-documenting as well-chosen meaningful block
names? And do you think it's good that adding an additional level of
block nesting in the middle changes the target of the break?

> Luiz Henrique once said, that you don't have to change the break
> statement if you insert another intermediate loop but IMHO you
> could find similar examples where a leveled break is easier.

Please give an example where "break 3" would be a good idea,
pleasing to maintain.

As best I can tell, your entire complaint hangs on a determination
to pick meaningless block labels, which really seems kind of
perverse. How much meaning does "2" or "3" convey? And why doesn't
it bother you that that meaning depends on details of the structure
of code spread around the region, which might change of the needs of
the program change?

-Bennett