OpenEuphoria

Re: New keyword added: continue

• Posted by CChris <christian.cuvier at agriculture.g??v.fr> May 28, 2008
• 878 views

Kat wrote:
> 
> Derek Parnell wrote:
> > 
> > Kat wrote:
> > 
> > Thanks Kat. 
> > 
> > > Derek Parnell wrote:
> > >> ... how can I be sure that there is not another 'goto restart'
> > >> elsewhere in the code?
> > > 
> > > You can't. You read the code to see if there is another "goto" that label.
> > >
> > 
> > How likely would this requirement increase the cost of maintenance?
> 
> In Textpad, drag the cursor over the label, and keypress for search. You
> could,
> i suppose, add a "came_from" var you interrogate in some way.
> 
> > > The same with "exit", "return", etc.. I have a fair amount
> > > of code that has "return" sprinkled around, and no one has
> > > ever complained about more than one place leaving
> > > the function.
> > 
> > I see this as a different issue. With 'goto' the question I raise deals with
> > how ones arrives at the label and has nothing to do with the 'goto'
> > statement
> > itself, but with 'exit' and 'return', the process flow to arrive at that
> > statement
> > is clear and local.
> 
> It is as clear as goto, i think. If i have a function, and i can return from
> it in several points, how do you know which return got you back out of the
> function?
>  
> > > One way to restrict the "where from" is to localise all "goto"
> > > to procedure/function blocks, and not allow it in top level code.
> > > Exactly like in OOEU.
> > 
> > Does the number of statements in a routine affect this position?
> 
> What?  I don't see the connection between statement count and use of any
> keyword.
> 
> > >> ** If I have to place another looping construct within the same
> > >> scope as the one above, what should I call the labels?
> > > 
> > > Umm, how about "loop2" ?
> > 
> > Does the requirement that a 'goto' needs a (unique within the scope) label,
> > reduce the amount of code that has to be read by maintainers? To me it seems
> > that using the combination of 'label xyz' and 'goto xyz' contains a lot more
> > redundant content than 'next' does.
> 
> But you *know* where goto will goto, and across languages, you haveto remember
> where each language differs, as well as how each human language interprets
> each
> of those other keywords, such as "next", "continue", etc.
> 
> > If such a loop containing labels, needs to be later nested inside another
> > loop,
> > what is the suggested naming convention, if any?
> > 
> > e.g. We start with ...
> >   restart1:
> >   loop
> >      -- some code --
> >      goto restart1
> >      -- some more code ---
> >      restart2:
> >      loop
> >        -- some code ---
> >        goto restart2:
> >        -- some code --
> >        goto restart1
> >        -- some code
> >      end loop
> >   end loop
> > 
> > But later this needs to be nested, such as ...
> > 
> >  restart3:
> >  loop
> >     -- some code ---
> >     restart1:
> >     loop
> >        -- some code --
> >        goto restart1
> >        -- some more code ---
> >        restart2:
> >        loop
> >          -- some code ---
> >          goto restart2:
> >          -- some code --
> >          goto restart1
> >          -- some code --
> >        end loop
> >     end loop
> >     -- some code --
> >     goto restart3
> >     -- some code --
> >  end loop
> > 
> > Would it be better to keep the existing label names as above, or is it
> > better
> > to rename them to keep the implied nesting level obvious?
> 
> Better to find a better way to code that. I would keep the labels more
> descriptive
> of what they do, and then not change them if you are wrapping or inserting new
> code that describes another function.
> 
> > >> ** Under what circumstanes might I have to rename the labels?
> >  
> > > Never, i believe. 
> > 
> > See above.
> 
> Did.
>  
> > > Just as an aside, one other cure for that
> > > would be nested procedures, which could be
> > > called inside the nesting procedure, and the
> > > nested one have the scope of the nesting one's
> > > vars 
> > 
> > Yes, nested routines would be very very nice. I suspect that we will have
> > this
> > ability soon, but not for v4.0
> 
> Cool.
> 
> Kat

It can be in 4.0 in a matter of days. The code works in interpreted mode in Æ.
There may be issues with translated code, as I recently discovered, but the bulk
of it could take like 3 days to port in, and a couple more for any residual bugs
(I have always stated tat that code was experimental and not thoroughly tested).

CChris