[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Re: why no "continue" statement for loops?
- From: "Bilyk, Alex" <ABilyk@...>
- Date: Mon, 23 Jun 2003 11:10:54 -0700
I don't see why "break [N]" is a complication. Want to exit a nested loop, use 'break [N]' otherwise, use 'break'. If you absolutely dislike 'break [N]' and 'continue [N]' on philosophical grounds, use 'break' and emulate everything else making your code full of clever tricks, there's no one here to stop you.
Why would an early exit statement from a single loop be considered good while the same concept extrapolated to a number nested loops would be considered bad? Sounds illogical to me.
Yes, a lot of people would argue that Lua is minimalist language that ought not to be cluttered with unnecessary constructs. But then, 'break' is not strictly necessary as it can be simulated and easier, mind you, than 'continue'.
Having 'break [N]' and 'continue [N]' would not infringe on any of the main Lua strengths IMHO while increasing its flexibility and usability especially for non-programmers and beginners, that is people with no programming preconceptions and stereotypes. Well, on the down side, it would probably make the binary some whooping 0.25% larger.
From: Tuomo Valkonen [mailto:email@example.com]
Sent: Monday, June 23, 2003 6:28 AM
To: Lua list
Subject: Re: Re: why no "continue" statement for loops?
On Mon, Jun 23, 2003 at 07:35:24PM +0900, Dylan Cuthbert wrote:
> I second this break <n> continue <n> syntax.
> So please, someone put it in the main lua source so I don't have to keep
> patching it.
While I don't miss continue, I'm not opposed to adding it. I am, however,
_strongly_ opposed to complicating the language with break and continue
levels. If you add those, you might just as well add 'goto' and we all
know how people feel about it. (I actually use goto in C, but only to
jump to an error handler at the end of a function. In languages like
Lua 1) most of the time there is no need for such handlers and 2) when
there is, there are many alternative implementations thanks to lexical
scoping and first-class functions.)