1. Re: 3.0 feature request: foreac
Christian Cuvier wrote:
>
>
> That means that adynamic goto involves a lookup at each occurrence -
> just what I meant. You've better avoiding them in tight loops.
Yes, but there's lots of stuff you shouldn't do in tight loops. If the
loop is big enough to contain gotos and labels, it doesn't sound very
tight to me. What about large, nested loops? A goto could save a lot of
headaches there by preventing the need for flags to jump out of a loop.
You'd actually improve performance in that case.
> My point was: why is there any spaghetti code at all, as it is much more
> difficult to maintain, let alone understand by others. That's because
> you can be lazy and peruse goto, abusing it in the process. Instead, you
> have to write structured code, which entails more thinking ahead and
> sometimes less flexibility (a repeat ... until construct in Eu would
> make a lot of code easier to follow imho).
Yes, abuse of goto is a bad thing. However, as time goes by, I find myself
closer and closer to Kat's position on goto. I think there are some
legitimate uses. Euphoria already has one (very specific) goto statement
in exit. It could be a lot more powerful, however, if it allowed you to
exit out of nested loop, for instance.
> I have a project in a very early dev stage, where you can goto anywhere
> (no cross routine stuff though), as long as you specify the list of
> private vars you may need at the goto target. This involves not only for
> loop indewes, but all vars defined in local scopes. This project has no
> name currently, it may inherit eventually from idEu.
That sounds overly complex to me, but I guess that was one of your design
goals, so OK.
> In the implementation I was referring to above, come_back just performs
> a stack switch (not using any hardware thing, which is too slow) and
> jumps to a saved address.
> I think the coder should be in control, in a simple to understand way.
> When taking a goto branch, you save the next statement resume address,
> which isn't automatically cleared. Use it whenever you need. Clear it
> whenever it's no longer relevant. That's what goto_clear does. I'm not
> sure there's a 100% foolproof system of ruls that could decide when to
> clear the saved address or not (my question to Kat).
Again, this just seems overly complex for little return, which was my
overall impression of the OpenEu specs. You start to trade the elegance
of Euphoria for the dog's breakfast of, say, Python [/flame].
Matt Lewis
