OpenEuphoria

Re: 3.0 feature request: foreach

• Posted by "Kat" <gertie at visionsix.com> Jul 15, 2005
• 439 views

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]). 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?

> * 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".

> * 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?

> 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
 

Kat