Re: 3.0 feature request: foreach
> Date: Fri, 15 Jul 2005 12:19:51 -0500
> From: "Kat" <gertie at visionsix.com>
> Subject: Re: 3.0 feature request: foreach
>
>
> On 15 Jul 2005, at 11:46, Christian Cuvier wrote:
>
>
>>>> > Subject: Re: 3.0 feature request: foreach
>>>> >
>>>> >
>>>> > posted by: Ferlin Scarborough <ferlin1 at bellsouth.net>
>>>> >
>>>> > Kat wrote:
>>>> >
>>>
>>>>>> >>> On 13 Jul 2005, at 20:48, Ferlin Scarborough wrote:
>>>>>> >>>
>>>>>> >>> There's only 2 gotos, and they replaced all those ugly case
>>>>>> >>> statements!
>>>>>> >>>
>>>>>> >>> Kat
>>>>>> >>>
>>>
>>>> > I was just picking at you, I know how much of an advocate you are for the
>>>> > goto
>>>> > statement. Personally, the only real thing I have against goto is that
>>>> > 98% of
>>>> > the programmers that use a language that contains goto, ABUSE it, and end
>>>> > up
>>>> > with all kinds of speghetti code, that you get lost in because they
>>>> > branch all
>>>> > over Gods creation.
>>>> >
>>>> > Now, if there was a way to implement the goto, and prevent abuse and over
>>>> > usage of it, then I would be all for that, but then, that is practically
>>>> > impossible. 
>>>> >
>>>> > Later.
>>>> >
>>>> > Ferlin Scarborough
>>>> >
>>
>>> 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.
> Ouch. I greatly
> prefer Matt's way of doing it. I'd prefer a fall-thru with no fatal errors,
> and
> some form of letting the code know if the goto happened, or seeing if it
> exists
> before the fatal error. Imposing the notion on the coder that they should
> always know what the code will do is prempting any future eval() or dynamic
> code generation.
>
>
>>> This has imho the following advantages:
>>> * provide a typing disincentive to using it;
>
>
> What?
>
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.
>
>>> * allow come_from() to tell the program what's the last goto that was
>>> taken. This would eliminate nearly all the ugly flags that crop up when
>>> you modify code built using goto;
>
>
> Nice to have come_from(), this is what i had in mind when i had asked for
> access to the call stack many years ago. I really needed that once, but Eu's
> sequences allow me to pass the come_from in the data i pass to the
> function i am calling, even tho i cannot return to that point in the code if i
>
> wish, which i could possibly have done if i could access and modify the local
> stack. I can do without the goto_came_from(), but it's interesting.
>
> I don't know what you mean by "ugly flags".
>
My Basic experience tells me that, for real life programming, you need
to set up various flags to inform the code of the way such or such
instruction was reached. An error prone process, rather inelegant.
Making the information built-in will save hours of debugging, and
probably have all the benefits you mentioned above.
>
>>> * allow come_back() to take you to the statement that follows the last
>>> taken gogo branch. This allows using some code both as main and
>>> routine-like.
>
>
> Interesting, but doesn't that make it into a gosub() or a regular
> function/procedure call?
>
It's kind of a gosub, yes. A code section which is to be used as a
routine must return (or yield), and as such must be a separate chunk,
with all the hassles of passing params to it. come_back() can turn some
portion of code into a returnless routine, with no overhead for passing
parms.
>
>>> 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.
Note that these goto features weren't discussed by the group, as it had
vanished beforehand.
>
> Kat
CChris
|
Not Categorized, Please Help
|
|
