OpenEuphoria

mainly syntax

• Posted by "BABOR, JIRI" <J.Babor at GNS.CRI.NZ> Feb 18, 1998
• 748 views

Cameron Kaiser wrote:

>I tried Python, but I'm not a fan of object oriented languages and at least
>Perl lets you not be OOP if you want to. (Although to my displeasure it's
>leaning OOP heavily these days. Gimme Perl 4 back!) But I did like the
>syntax; very lucid 

It depends what you want to do, for some tasks OOP is very handy. For
example design of GUIs. For a number of weeks now I have been trying
to come up with a relatively simple GUI framework and I am finding it
very, very difficult without resorting to some form of OO. The trouble
is, because Euphoria does not allow parameter parsing by reference
(what a pity!), I have to set up a number of external structures to
hold even transient values, and the whole thing becomes very messy.

Cameron also mentioned syntax. I think it is quite important, because
computer languages are a bit like religions, and syntax matters a lot
especially in the early stages of conversion. I like Euphoria's
syntax, but I must admit I am getting tired of some aspects of it,
e.g. endlessly typing 'end procedure', 'end if', 'end while', etc. It
is just as useful as 'begin... end' brackets, or the semicolon in
pascal... I am not advocating Python's use of indentation, it is too
controversial, but what about replacing the whole lot of these
crutches with a simple "." (dot). So instead of, say,

    if x then
        for i=1 to x do
            do_something()
        end for
    end if

we would have

    if x then
        for i=1 to x do
            do_something() ..

Neat,eh?! The first dot for 'end for', and the second one for 'end if'.
And the compiler/interpreter can tell us anyway, if and why the dots
do not match.

And while I am raving about syntax, I cannot understand this
completely artificial distinction between procedures and functions.
After all, functions are merely routines that return a value while
procedures do not. So why a different mechanism? The so called
'safety' argument is even weaker here than for the crutches above.

Perhaps one more syntactic niggle: I seem to be writing about thousand
times a day something like x = s[length(s)], or s1 = s2[m..length(s2)]
This could easily be replaced by, say, x = s[-1], or s1 = s2[m..-1],
which is more elegant and saves the function call overhead as well.

I better stop here, otherwise Ralf will justly start complaining about
the amount of space I usurp on this server. Jiri