OpenEuphoria

Re: WISHLIST.TXT

• Posted by Juergen Luethje <jluethje at gmx.de> Aug 22, 2002
• 447 views

Christian <christian.cuvier at education.gouv.fr> wrote:

> Hello, dear EUfolks !

> Here is a wish list in which I compiled everything I could think as an
> useful enhancement for Euphoria (exchanged some mails with R. Craig on
> this).
<snip>

Here is an extract of "wishlist.txt", which was attached to your post:

------------------------------------------------------------------------
<snip>
>    Direct indexing of implicit sequences would make some codin much shorter.
>    That
> is the date()[MONTH] exemple.

Even simpler: date(MONTH)

<snip>
> One-layer visibility in includes.
>    An include file used as a library must contain the user function as well as
> theauxiliary functions they use. The only differenc between them is that the
> first category is declared global. Would be much clearer if the auxiliaries
> coud be in another file. What if the auxiliaries themselves need lower-level
> utilities? You must either declare them as global in another include file, or
> mix them in the library.
>     A solution to the confusion could be a *friend* keyword that could apply
>     to
> any local symbol. It would mean:"make this symbol known to a file that
> includes
> this file". This way, you can have one file by functional layer.

Very good idea! I mean: "_very_ good"! Did I already mention, that this
in my opinion is a *very* good idea? ))  IMO this fits perfectly to
the Euphoria philosophy.

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

<snip>
> Variable accessibility.
> -----------------------

>    Right now, there are only three scopes for a variable: routine-wide
>    (private),
> file-wide (local) and project-wide (global). So, when two separate routines
> (most of the time, one is calling the other) need to access a variable, this
> variable must be at least file-wide.
>    Assume now that routine R1 and R2 need variable V12, R2 and R3 need V23 and
> so forth: all symbols end up in the same file, while a small portion of the
> file uses each of them. This is a worst case scenario, but it happens.

>    Here are several ways to overcome this:
<snip>

4) Here is another way, IMO simpler to use than #1-3 (the variable can
   be accessed by any routine, that declares it as "shared")

   function r1()
      shared integer v12
      -- etc.
   end function

   function r2()
      shared integer v12, v23
      -- etc.
   end function

   function r3()
      shared integer v23
      -- etc.
   end function


> Static variables
>    In some fields, it is not rare that we need to remember some values taken
> by routine variables. Declaring them static would allow them to retain their
> value between two calls.

Static variables will be useful.

> Optional argument for exit statement
>    What happens if you first defined a loop with exit statements, then
>    improved
> it so that the exit statement is inside an inner loop? Answer: the eit
> statement
> must be accompanied by the setting of an auxiliary variable (sort of error
> code).
> And, at the end of the loop, you must test the variable and conditionally exit
> the outer loop (only one level was added, right?).
>     An elegant solution to this bloated coding would be for *exit* to have an
> optional argument specifying the number of levels to jump up out. Default
> value
> (see below) would be 1.
<snip>

This will be very useful!
(For instance, in PowerBASIC you can write "exit,exit,exit" but it's of
course much more elegant to write "exit 3".)
------------------------------------------------------------------------

Regards,
   Juergen