1. Re: What's Holding Euphoria Back
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Feb 04, 1999
-
Last edited Feb 05, 1999
>Also, there's another issue somewhat related to this that just struck me.
>Let's say that someone out there *is* thinking seriously about backing
>Euphoria, despite the name. They've heard some of the details about it from
>programmers, and they want to check it out. So they go to the official
>Euphoria programming page -- and are greeted with *garish* colors, and the
>following welcome message:
>"This page provides the latest info on Euphoria - a nifty new programming
>language for your PC. Euphoria is fast, flexible and fun; simple, safe, and
>sexy!"
>
>This doesn't exactly encourage anyone to take the language seriously.
Well, its a tiny little better than the old page.
[forward references]
>I suppose we could just have the interpreter make *two* passes through the
>source code -- once to get all the routine declarations, then its usual
pass
> -- thereby avoiding the need for any "declare" statements at all. But then
>it shoots down the whole beauty of Euphoria's initial design, requiring
only
>*one* pass through the source.
Well, yes and no. I am in favor of being able to use mutal recursion without
declare statements.
But mutal recursion should only be possible accros multiple include files,
and only when they include each other directly.
Within an include file: linear (reads well, better maintainable)
Wintin an project: modules (no real order)
>I agree totally and wholeheartedly with both points made here. Namespace
>issues are a major headache for any Euphoria programmer. The whole
reverse()
>fiasco -- involving Euphoria 2.1 alpha and old versions of Win32Lib -- is
>only the most recent example of this. I think we should be allowed to
>redefine *any* routine, not just the built-in ones -- the interpreter can
>generate warning messages for this, very much like the existing warnings
for
>the redefinition of built-ins.
Well, not within the same include file, unless their scope differs. Example:
declaring the same procedure global twice in the same include file should
not be allowed. But when one is local it should be allowed. Overwriting
routines globally declared in other include files should off course *always*
be allowed.
>And I obviously agree with Dave's remarks about structures. I won't go into
>this again, since I believe I've already made my views on this point clear.
>(Do I hear strains of the "Hallelujah Chorus"?) :)
Read my response and consider my implementation.
Ralf
