OpenEuphoria

Re: Euphoria Interpreter design

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Feb 23, 1999
• 454 views

>Poorly organized? A poorly organized code is what you get when you are free
>to declare things wherever you like (VB comes to mind). Euphoria
>declare-before-use is one of it strong points. It enhances redability &
>conceptual organization.


I completely disagree. I will give you an example of a program im working on
now.
It has a special 'register' function that registers the routine id of a type
function, its name and an error message.

It would be most clean if these registrations could be done *after* each type
check statement (that makes most sense)
However, Euphoria forces you to order your code differently, because the
registration routine uses those types in its
declaration as well.

    type byte (object x)
        return integer (x) and x >= 0 and x < 256     -
-- btw this doesnt work, see Robert response/explenation for this
        failure in some previous mail.
-- I mean come on Robert, this is obviously a (if not *the*) case where
        short-ciruiting makes sence, much more
-- than in while and if-statements. Oh and I will lookup that quote that
        you said didnt exist.
    end type

    global function register (byte x)
        -- code
    end function

register (routine_id ("byte"), "byte", "An integer value between 0 and 255
    is expected.")

But like this, I know off zillions of other examples where linear is not the
cleanest way to code your program.
However, there is an argument that linear programming is by definition more
elegant. (it isnt more powerfull, we'll agree)
That its better to be forced to program 'clean'. But I have seen no prove that
linear programming is the best and most clean
choice for all programs.

And dare I say it, I could order my code *much* better, than how Euphoria forces
me to order my code.

This is why agree (if you want to enforce something), that within an include
file declerations should be linear, but on the
global 'scope' (that is calling routines from *other* include files) there
should be no real order. WHy ? Because often we
havent written and shouldnt be forced to mess with the include files. If two
include files include each other, than both should
be able to call each other. This however is not currently true, what is true, is
that it is very possible that we accidently
calling other global identifers that we did not include. Also do to the linear
programming order. (where *every global
identifer* is accesable from *all* code that follows, including the code that
specified it did not want anything to do with
those identifers.

Ralf