Re: 3.0 feature request: foreac
> Date: Fri, 22 Jul 2005 14:05:39 -0500 From: "Kat" <gertie at visionsix.com>
> Subject: Re: 3.0 feature request: foreac On 22 Jul 2005, at 18:50, Christian
> Cuvier wrote:
>
>>>
>>>> > Subject: Re: 3.0 feature request: foreac
>>>> >
>>>> >
>>>> > posted by: Matt Lewis <matthewwalkerlewis at gmail.com>
>>>> >
>>>> > 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.
>>>> >
>>
>>> True for static goto; does it still hold for computed goto?
>
>
> If all the :targets were known, there is a slight overhead for *one*
> computation (goto 1+2), and then an optomised *table* search of the :target
> list. As opposed to a stack of if-then-else statements where each conditional
> if-then source line is interpreted and all those comparisons be made *as they
> are run across*, plus the flow control flags are evaluated for each if-then in
>
> the stack.
>
Ok, but a lot of goto statements go forward, if only so as to exit
blocks. Hence, the interpreter doesn't know how to compute the target
branch address till possibly very late.
>
>
>>>>>> >>> 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.
>>>> >
>>
>>> My personal view is that having more dedicated flow control instructions
>>> like next/continue, retry, , having optional relative/absolute optional
>>> arguments so as to exit nested loops etc would be cleaner than using
>>> goto and would supersede it. Migh not be the majority opinion though.
>
>
> Right, introduce more and more reserved keywords, with all their gotchas, to
> do what goto can do.
As many gotchas as exit, I think.
>
>
>>>>>> >>> 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.
>>
>>>
>>> The idea is: you can't goto in or out of a routine; otherwise,
>>> everything should be possible. Impressing tighter restrictions would go
>>> against what I consider as elegance.
>
>
> But you just got thru saying:
>
>>> My personal view is that having more dedicated flow control instructions
>>> like next/continue, retry, , having optional relative/absolute optional
>>> arguments
>
> Which smells like tighter restrictions on more keywords to me. What did you
> want?, an exit_for(howmany), exit_if(howmany), exit_while(howmany),
> exit_if(howmany), and then a forwards_ and reverse_ for each of those? What
> about a exit_for(2)_while(1)_reverse ? You could exit(), retry(), continue(),
> resume(), keep_on(), proceed(), move(), etc. And why not use a new set of
> keywords for sleep(), like pause(), hold(), go_slow(), stay(), creep(),
> mozey(),
> delay(), persist(), remain(), delay(), detain(), etc, each with different
> parameters and side effects?
>
:) this is what Eu does with it "end for","end if" and so forth. This
safety net sometimes proves to be a real nuisance, when indenting back
is a clear enough end of block mark.
Your proposal sounds as too much of a good thing to me.
- exit currently works for for and wwhile loops, leave it that way.
- There's no "exif" keyword to exit an if block, that could be a nice
addition to the language.
- Both could benefit from an optional parameter, either a (computed)
label to exit the block just labelled, or an integer giving the relative
position of the nesting block to exit. Thus "exit 1" would exit the
first nesting block, while "exit -1" would exit all nesting blocks.
For iteration control, "next" and "retry" are useful, and could benefit
of the same optional parm facility.
Still need a goto? Yes, probably, but far less often.
I'm advocating a fully flexible select/case statement, and I started to
outline some code for it. You'd be appalled at how many reserved
keywords it adds: [end] select, case, break, stop, otherwise, reselect,
default. Some of them with the optional parameter.
>
>>> However, this raises the issue of scoped variables when gotoing into a
>>> local scope. Which is why the extra construct is needed.
>>> Local scopes (like in C) largely enhance code readibility by avoiding to
>>> clutter the current namespace with symbols which are needed in a short
>>> section of it only. This is why I consider it useful to implement them,
>>> at the price of making goto trickier to implement.
>
>
> Make it even easier: forget the others, and add ONE versatile and elegant
> word: goto.
>
> I think you are just terrified of:
> sequence list
> list = {"a","b","c","d"}
> goto list
> and the elegant Euphoria dutifully runs thru the list and overwhelms you.
>
What would that statement do? I can't currently see how this statement
relates to the one above it.
>
>>>>>> >>> 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].
>>>> >
>>
>>> Same as above. I may decide that after all I don't need goto at all.
>
>
> <sigh> It's amazing how you can use the same words which prove my point,
> and come to the opposite conclusion.
>
Perhaps because we don't have the same definitions for "elegance".
Having as few keywords as possible is an option. Having clear constructs
which make debugging easy and more closely match the program flow as it
mentally exists for the coder is another option. I'm leaning heavily
towards the latter.
CChris
> Kat
>
>
|
Not Categorized, Please Help
|
|
