OpenEuphoria

Re: WISHLIST.TXT

• Posted by christian.cuvier at education.gouv.fr Aug 23, 2002
• 427 views

----- Original Message -----
From: "Juergen Luethje" <jluethje at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: WISHLIST.TXT


>
> Christian <christian.cuvier at education.gouv.fr> wrote:
>
> <snip>
> > Resume statement:
> >    A "resume" statement would give control to the first statement in a
loop,
> > performing the operations that an *end loop* normally would. After all,
> > a new keyword is not even necessary: end while and end for can be uesd
just
> > as well.
>
> I'm afraid I didn't understand what you mean. Could you please give an
> example?
>

    Hi!
    The *end for* or *end while* statements - I'll call them *end loop* -
return control to the top control statement in the loop (the *for* or
*while* thing, with condition testing and everything).
    In Euphoria, *end loop* statement can appear only as the closing
statement of the loop.
    My suggestion is that it could appear anywhere inside the loop,
returning control as described above.

    In other languages, this functionality is assumed by specific keywords:
*resume* (SAS), *iterate* (some Basics), *continue* (C)... . My observation
was that a new keyword is not needed, just extend the availability of an
existing one.

    So, instead of writing

while <cond1> do
    ...
    if not(<cond2>) then
        ...
        if not(<cond3>) then
            ...
        end if
    end if
end while

you'd have the much cleaner, and completely synonym:

while <cond1> do
    ...
    if <cond2> then end while end if
    ...
    if <cond3> then end while end if
    ...
end while

If it is a problem to tweak the interpreter into understanding this use of
*end loop*, then one of the other known keywords (*resume* is shorter) could
be introduced for this specific purpose.

Clearer?

BTW: on dubetyrant statement:

>7.That darn interpreter is reliable.Adding all kinds of new complexity
>could jeopardize the stability of the thing,that wouldn't be good.

Obviously, stability is an issue, and that's why I said resisting too change
is not unhealthy by itself. Some features may never be mplemented, although
they would be very convenient, for this very reason.

Frankly, I think that 90% of what I'm suggesting cannot compromise Euphoria
interpreter stability in any way. As for the remaining 10%, I don't know. I
paid special attention in seeing to it that nothing proposed could break
existing code.

The "Not planned in any future" section I suggested could state some of
these features that might be too risky to implement, with a sketch of the
reason why. Careful reading could then clarify issues and give a better
understanding of how Euphoria works, which will mean better Euphoria coding.

>2.Loops.I have found that the while,if,for loops work for anything
>I need,and quickly too.

Hey, very smart people coded marvelous things in Fortran77 30 years ago.
Want to use this again? It is most of the time a matter of convenience in
writing and code readability and maintainability.

After all, one could say: Euphoria can interface with C and ASM, so do any
advanced trickery through this interface. I don't think it is either clean,
desirable or secure, but it may work...

Best regards.

Chris