OpenEuphoria

Re: Goto (Was Re: Open Source)

• Posted by CChris <christian.cuvier at ag?icult?re.gouv.fr> Oct 29, 2007
• 801 views

Chris Bensler wrote:
> 
> CChris wrote:
> > 
> > I'll try submitting shortly a set of Eu front end files that add a number of
> > imho needed enhancements to the language. The additions are:
> > * forward routine calls allowed, using
> > }}}
<eucode>
> > forward function f(integer z)
> > n=f(3)
> > --- some code here
> > function f
> > -- usual routine body here
> > </eucode>
{{{

> 
> Is prototyping the way to go?
> For functional purposes, it's not needed, afaik. It's purely for distinction,
> correct?
> Would it not be better to have some syntax that is used specifically for each
> call to a forward reference?
> Such as:
>   n = ~f(3)
> 
> .. which makes it directly clear what is intended at the point it is used,
> rather than the point at which it is defined.
> 

~ had been repeatedly suggested to ignore the return value of a function, so I
didn't consider this new operator. A keyword sytax would be awkward, and there
are not too many unused symbols on the keyboard - and they may not be easy to get
on all sorts of keyboards.

The prototyping is necessary, because the interpreter needs to know which among
f(3), f(3,2) or f() are valid call, specially with defaulted arguments.
Additionally, it may seem more palatable to some because you still can't use a
routine or variable before declaring it. Defining can be postponed.

> > * new scope keyword, to declare variables local to part of a routine/top
> > level
> > code, possibly shadowing existing symbols;
> > * nested routines are now supported. For consistency reasons, you can call
> > only
> > a routine which is a direct descendant of any ancestor of te current
> > routine.
> > * new loop
> > }}}
<eucode>
> > loop do
> > -- some code
> > until some_condition
> > end loop
> > </eucode>
{{{

> 
> > * exif exits an if block;
> 
> Can you give an example of how this would be used?
> 

if I_got_here() then
  if some_cond then
    bla()
    if something_went_wrong() then
      exif 2 -- exit the whole thing
    end if
    -- more code
  else
    do_nothing()
  end if
end if

You could label the outer block, for the following variant:

if I_got_here() label "outer block" then
  if some_cond then
    bla()
    if something_went_wrong() then
      exif "outer block"
    end if
    -- more code
  else
    do_nothing()
  end if
end if

For the simplest cases, using numbers is simpler I think, as it avoids te visual
overhead of the label. But, in all generality, labels should be preferred, since
they protect the code against any loop/if block change. That's why I'm supporting
both systems.

> > * inside a oop, next skips the rest of the current iteration and performs
> > any
> > code prepring the next;
> > * retry jumps to top of loop, without executing the code that prepares next
> > iteration;
> > * all loops can have a label attached to it, like this
> > }}}
<eucode>
> > for i=1 to n by 2 label "my string" do
> > </eucode>
{{{

> > * exif/exit/next/retry now have an optional parameter, either
> > + a nuber of loop above current one (1 = loop above, 2=loop above the
> > latter,...)
> > + a negative number, to count loop levels backward (-1 = topmost loop, -2 =
> > all but topmist,...)
> 
> I don't agree with the use of hard-coded exit values.
> I beleive this would be extremely problematic.
> 

Theoretically right, but let's everyone decide by himself...

CChris

> > + a string, which must have been defined as a label prior;
> > + the name of a for loop index.
> 
> I think I would personally opt for "exit to label" only.
> It covers every case as well as reduces confusion and complexity.
> 
> > * defaulted routine parameters, with ability to default any parameter, not
> > only
> > the last one(s)
> > 
> > The only mod to backend would be to update be_syncolor.c so that the trace
> > screen
> > displays the new keywords as such.
> > 
> > I'll submit this to user contributions spùewhere in november. If I ever
> > write
> > some new code in Eu, I'll probably use and require that new interpreter.
> > I'll
> > attempt to also implement pass by reference, but this may or may not work.
> > An
> > earlier implementation I had just does no longer work with multitasking.
> > 
> > CChris
> 
> Chris Bensler
> Code is Alchemy