OpenEuphoria

Re: From a newbie

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Sep 20, 1998
• 618 views

>>Euphoria 2 will short-circuit, and give a warning message with those
>>programs where it could led to a problem, when the programmer is not
>>consider the short-circuiting..

>Will do or does?

The next release, not yet available to public *does* short-circuiting.. its
already put in the ex.exe
It only works in if's, not in normal expressions though. (I think, some one
correct me when Im wrong)

>>>Euphoria language extension suggestions:
>>>
>>>1. If answer for Q2 is "No" make it possible - in/out arguments.
>>>in - argument is an input (default)
>>>out - argument is an output
>>>in out - both as input and output

>>I disagree, the programmer using the function wouldnt preciously know
which
>>variables could or could not have been altered.

>Yes, the programmer knows it - right from the function interface he/she
declares (using in/out).

Actually it is quite an interesting approuch, no return value, but just
using the argument list, for communication both ways.

I must admit its interesting, but Robert will never ever add this. It will
break all original code anyways.
And it doest exactly fit in Euphoria's priorities. Its completely based on
the ideology of readability, safety and speed.

>>However, a very nice replacement trick for this is: (something I would
like
>>to see added)

>>{ name, addres, phone } = lookup_db (name)

>Oh, great! It looks like unification (what about anonymous variables?).

Robert, I must agree function calls shouldnt be sliced, but this way, no
value gets discarded.
Why not add the { .. } assignment ??

Many are in favor of this...

>>>2. Structured gotos (as in Java) and exceptions implementation.
>>I find them a bit scary.. but there are cases they are handy..
>>What about this one, Robert ?
>>exit (3) -- jump out three levels

>Now, I disagree. It's only partial solution - I don't know in advance if I
put the code with exit(3) inside/outside
>another block (so the level I want to jump out could be changing). The
labeled (i.e. named) statement, which is
>to be jumped out to, is much more robust and clear.


True, yet, up until now, we dont have labels yet, it will take a lot of
consideration before labels are added.
On the other hand, I must admit, its very helpfull, and actually eliminates
some of comments, you would add anyway, to describe the crucial loop, so it
does add for more readability, and it makes an algorithm look so much more
simple and natural. Robert ? I know you are almost burried in suggestions,
but I think its time another priority is added to Euphoria.

These already exist:
-readability (it has to look easy and simple)
-safety
-speed

Why not seriously consider upgrading the power of expression.
All this suggestions (in this mail at least) if were used, make a program
look *so* much more natural, the way we were thinking of the algorithm.

We dont think in flags, to get out of multiple layers of a loop-construct.
We dont think in assigments of every element from a return value.

Also, while we're at suggestions any ways.
Lets make a list, people:

- structures (no dicussion needed anymore, is there ?)
- { .. } assignment (any one disagrees ?)
- labeled goto's (it wont happen, I think, but I totally agree with Tom)

And, these non-discussed suggestions:

a global variable called discard.
Its ok, to *not* use a return value, as long as you can easily see, you are
doing that.

discard = myfucn ()

I mean, every one can see the return value will not be used.
Why not add this global variable, which use of it in an expression would
only be allowed when the expression itself is stored in discard again.

For example:

puts (1, discard)
*crash* discard can only be assigned values)

discard = { x, y, discard }

*legal*

Any pros, cons ?

Ralf