[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: New scoping rule for "repeat" and "continue" patch
- From: Rici Lake <lua@...>
- Date: Tue, 4 Oct 2005 04:43:00 -0500
On 4-Oct-05, at 12:46 AM, Diego Nehab wrote:
Sorry, I was away and missed this nice thread. I feel guilty because I
bothered Roberto some time ago with this change, so now it is my dutty
to defend it. :)
Think first about why this could be a good idea. In the old style, you
would need to declare "done" outside of the "repeat" loop in order to
be able to read its value in the until expression.
First, this makes it less obvious that "done" is in fact only used
inside your repeat block. Second, you can't use a on-liner anymore.
Sure, all that makes sense to me. However, it does create a scoping
anomaly, which could best be resolved by making the scope explicit
with an "end" statement (imho) in which case you could use multiple
'untils' in the loop. Curiously, just a couple of days after I made
that suggestion, I ran into Olin Shivers ICFP presentation, in which
he proposes (a much more elaborate) loop-construction language which
has exactly the same feature (although he also implements a number
of other primitives.) More on that later, though :)
Now, ignoring the fact that we do *not* have a continue statement in
Lua, at least not yet, I don't understand what is it that broke which
local l = io.read"*l" or "quit"
if l:match"^#" then continue end
local g, rest = l:match"(%S+)%s*(.*)"
done = handle[g](g, words(rest))
If you assume the old scoping rule and use the above declaration, you
will still skip assignment to "done". Will Lua detect such a problem?
Does this loop not work the same as the other? I might be just tired.
The problem with the hypothetical continue is not that "done" is "left
uninitialized" in the sense that it is "still nil". It doesn't exist
at all; the slot which it will occupy has been used by Lua as a
temporary in the call to l:match, and consequently it will have a
random value (which is probably *not* a false value) so that the
loop will exit prematurely. You'd have to actually install the
continue patch to see that happen, I supppose.