lua-users home
lua-l archive

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


Bennett Todd wrote:
> 2000-05-02-19:53:16 Edgar Toernig:
> > - Another thing with for-loops.  Why did you to made the iteration
> > variable an automatic local?  I considered this while implementing
> > for-loops for 3.2 but discarded that idea pretty fast.  It's too ...
> > inconsistent!?! ... special? ... ugly!  Look at this:
> >
> >       n="foo"                         -- global n
> >       print(n)                        -- foo
> >       for n=1,3 do print(n) end       -- 1 2 3
> >       print(n)                        -- foo
> >
> > Ok, sometimes it may be easier to not have to write the "local n" and
> > the generated code saves one instruction but it looks so ... wrong.
> Interesting. I think it's fascinating that you dislike this; it
> suggests that there's some basic difference in our programming
> backgrounds or something. I really like having the iterator variable
> for a loop construct be automatically local to that loop. Using the
> same variable as a global and a loop counter is sorta tacky looking,
> I probably wouldn't usually do that, but using a common variable
> name like "i" for a loop index is a comfortable style, and I like
> the feature that you can keep doing it as you nest loops, only
> switching to distinct loop variable names of you expressly want the
> outer loop's index to be accessible within the inner loop.

Of course it has a lot of advantages.  That's why I considered it myself.
When I say it look wrong I meant it in the scope of the language.
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*

I can live with these auto-locals.  I just think, that it's a new
special case / new rule that should be avoided.

> > - About the break I have to repeat myself:  I don't like the concept
> > of break-labels.  If you want labels, add a goto but not a break.
> > If you want a multi level break, use break-levels.  Sorry.
> Another interesting one. I much prefer breaks with labelled blocks
> (e.g. perl) over counted break levels (e.g. /bin/sh) or gotos.
> Breaks are more constrained than gotos, it's more immediately
> obvious to me what control flow is happening.

I'm not a fan of gotos but sometimes they are useful (I'm not asking
for them in lua).  But labeled breaks are a nuisance.  First you
have to invent silly names (L1,L2,L3).  Then you don't know where
to write them (indented, left flushed, ...) and at last, if you
see some "break foo" you have to search for this damned label to
see what loop you leave.  A "break 2" gives you a direct context,
and you don't have to invent a label-syntax.  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.  That should not be
the point to base ones decision on (hmm... sounds strange *g*).

Ciao, ET.