1. Re: 3.0 feature request: foreach
Christian Cuvier wrote:
>
> > From: "Kat" <gertie at visionsix.com>
> > On 15 Jul 2005, at 11:46, Christian Cuvier wrote:
> >>> The latest version of the OpenEu specs require any goto statement to
> >>> have its owbn label.
> >
> >
> > That smells like it would fail at compile time if there is no target in an
> > explicitly declared goto(target), which is one thing, but that inherently
> > then
> > fails if you have a goto(computed_target) like goto(x[23]).
>
> The specs don't support computed targets. In my unreleased idEu
> preprocessor, which has macros, everything in macros is dynamic, so that
> no compilation fails. Performancewise, I'm afraid it would be
> disastrous. Not mentioninfg the headaches while debugging.
I don't think so. In ooeu, I keep a list of all the targets that are
in scope. All top-level targets are lumped together, and each routine
has its own list. If it's a static label and a static goto, then it's
optimized to a straight jump in execution. Otherwise, I do a lookup,
first checking static labels, then variable value labels. There's also
an option to turn on strict goto behavior or not, so that an invalid goto
just falls through to the next statement.
>
> Most of the anti-goto rhetoric comes from the fact that it is all to
> easy to abuse. And it is, as it's easy to write "goto target" and forget
> about all loop rules. Requesting to label the goto statements
> themselves will make them a bit less attractive. But the extra label
> isn't just red tape, see below.
I don't think loops are why people are afraid of goto. It's more that they're
afraid of spaghetti code, where gotos jump all over the place, and it's
not easy to see how everything is supposed to flow together. In ooeu, it's
not illegal to jump into a loop, though I warn that for loop behavior is
undefined, and you shouldn't do it. I don't see any problems with jumping
into a while loop, though. And jumping out doesn't do anything that exit
doesn't already do (if you look at execute.e from eu.ex, you'll see that
exit is precisely a goto).
> >>> there's a goto_clear() to avoid spurious results from come_from() and
> >>> come_back(), as well as "far" versions to go to top level code in
> >>> included files (namespaces actually) from anywhere.
> >
> >
> > That should be automagic. If the code execution hits any executeable code
> > following a :label , previous goto flags should be cleared and the new valid
> >
> > data inserted, as applicable. By waiting till executeable code is hit, you
> > avoid
> > premature clearing when you hit code like goto("Number 5"):
> >
> > :"Johnny Five"
> > :"Number 5"
> > :serial number 5"
> > -- code here
> >
>
> You're right, but are you always right on this one? A lot of people will
> frown at the idea that they must rely on the innards of the interpreter
> to trust their code flow that they try to optimize so carafully as to
> use gotos to that effect. I'd be a bit reluctant myself. But again, if I
> can get a proof that it would always work as any sensible coder would
> expect, I'd agree that goto_clear() is redundant and thus useless.
I don't understand what you mean about 'rely[ing] on the innards of the
interpreter to trust their code flow.' That sounds like you shouldn't
trust the interpreter to manage the call stack. I'm a little wary of the
come_back() thing in general. I suppose I could think of some good reasons
for it (error/exception handler within a routine), but I'm not sure I'd
want to implement it. That's where you'd really take a performance hit,
I think.
Matt Lewis
