Re: Euphoria Interpreter design
>I'm *sure* there are many cases where some programmer-defined
>order will be "better". The point is that Euphoria's
>define-it-before-you-use-it order is *machine-verified*.
>A arbitrary order invented for each program by an artistic
>programmer is *not* verifiable, and therefore can't be trusted
>to have any consistency, by others, or (eventually) even by
>the programmer himself.
I agree, that often the define-it-before-you-use-it order is the nicest. Im just
questioning the need for a full and consistent
restriction.
Like I said before, within in include file, it would often be the cleanest to
maintain such a linear order (I would), but
considering include file A and include file B, which include each other. I think
they should be able to use each other's code.
First of all, the programmers is not certain of the order anymore, since its in
seperate files, secondly: an include file is an
'individual' part of your program. You seperate such parts so they can work
independently. So you can debug them independently.
As long as the interface through global identifers remains the same, the rest of
the program is able to use it as intented,
while internally much can be changed. The whole idea behind an include file. But
linear order removes part of that 'independent'
freedom of an include file. What an other include file has already included and
in which order, can have an influence on which
routines are called and used and possible conflicting as well. I dont think we
should be able to change *anything* for an
include file, except when it *lets us* by using its global identifers.
If you want to maintain the restriction, and I do understand the arguments to
that choice, at least looses it up *somewhere*.
Like considering multiple include files. I can give examples of projects were I
had different parts that had to mutally call/use
each other. I could get them to work, using routine-id's, but then I would need
to modify both parts seperately for this special
exception. And when both libraries are meant as api's, its just much more
elegant if you would be able to acces them (and their
constants and other identfers) the way it was intented withouth some weird hack
that (your words) alerts us.
>Knowing that define-it-before-you-use-it is *enforced* for all
>Euphoria programs, makes it easier to understand and maintain
>other people's code, and probably your own as well.
>The routine_id mechanism lets you call things that come later,
>but you can clearly see in the code that a special call
>(call_proc, call_func) is being made, so you are alerted to
>what is going on. A user-defined symbol can never appear
>in the source code before it is declared.
Btw, Robert, considering this, wouldnt it be able to routine_id () a global or
local variable and/or constant and have it work
like a function (with zero arguments) ?
Nevertheless, im not convinced. I still want mutally callable include files. I
dont mind a forced linear order *within* the
include file. (local scope only thus).
Ralf
|
Not Categorized, Please Help
|
|
