1. EUPHORIA's New Name...
Maybe Rob would like some suggestions about language names...?
I think we should get all the suggestions from the users and then vote on it.
Someone can set up a voting booth OR we can simply discuss it here on the list.
It's also time for a dedicated domain name for EUPH- I mean, the language we all
know and love... I'd be willing to donate time in developing the site, although
I'm sure the Craig's have fun doing it themselves... 
"Boehme, Gabriel" wrote:
> "Cuny, David" <David.Cuny at DSS.CA.GOV> wrote:
>
> >My 2 cents on what I think make Euphoria difficult to "sell":
> >
> >[The Name "Euphoria"]
> >
> >"Euphoria" is a name that makes people giggle. I've put together a number
> of
> >small programs in Euphoria at work; when people ask what they are coded in,
> >the answer is now a "non-standard language". I don't expect the name to
> >change (there's too much invested in it at this point), but it *is* as
> >issue.
>
> After I discovered Euphoria -- and once I finally understood the nature of
> sequences -- I breathlessly described to friends and family alike all the
> wonderful features of this "revolutionary programming language" I'd
> discovered. They all listened seriously at first, and seemed impressed with
> the ideas of sequences, run-time checking, and the other excellent features.
> But the moment I told them the actual name of this "revolutionary
> programming language", the unanimous response was laughter -- either
> outright, or stifled. At first I didn't realize it, but I've come to realize
> just how much the name prevents people from taking the language seriously. I
> personally think it's an awesome name, but Dave's right -- it *is* an issue.
>
> 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.
>
> <snip>
> >[Forward References]
> >
> >People coming from other languages are used to using forward references -
> >but it's *painful* to do in Euphoria, and there is the overhead of having
> to
> >create a sequence to hold the arguments:
> >
> > -- create a holder for the forward reference
> > integer foo_id
> >
> > -- define a prototype for the function
> > function foo( integer x, integer y )
> > call_func( foo_id, {x, y} )
> > end function
> >
> > -- define the "real" function
> > function forward_foo( integer x, integer y )
> > -- code goes here
> > end function
> >
> > -- resolve the reference
> > foo_id = routine_id("forward_foo")
> >
> >That's a lot of work that could *easily* be done by the interpreter - just
> >allow the prototypes:
> >
> > -- qbasic syntax, perhaps "forward" is a better keyword
> > declare function foo( integer, integer )
> >
> >that are resolved later:
> >
> > -- define the "real" function:
> > function foo( integer x, integer y )
> > -- code goes here
> > end function
> >
> >Since the interpreter knows what the proc looks like, it could resolve the
> >call *efficiently*, instead with all the overhead of the current method.
>
> I must disagree here. When I was first learning Euphoria, I was impressed
> with how it "forced" you to structure your program routines. When searching
> for a function or procedure, you *always* knew you could find its definition
> *before* any place where it was used. The old QuickBasic "declare" syntax
> would seem like a step backwards to me, either requiring the programmer to
> write the declares themselves (which I would *hate* to do), or requiring
> some utility to automatically scan the source code and create the "declare"
> statements at the top or the source code. Either way, the beginning of our
> Euphoria source code would be cluttered with all these "declare" statements!
>
> 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.
>
> I was somewhat upset with the introduction of routine_id() at first, but
> obviously this was a necessity for programming in a Windows environment. My
> feeling is that the current way routines are defined in Euphoria is the best
> way, forcing you to organize your code logically. The "pain" involved in
> creating "forward references" in Euphoria should probably be considered a
> deterrent -- use them only if you really, *really* need to.
>
> I suppose programmers coming in from other languages will complain about how
> Euphoria "forces" you to do this. Actually, Euphoria forces you to do a lot
> of things -- initialize your variables, use valid subscripts, pass valid
> parameters and so on -- which *greatly* helps reduce the number of dumb
> errors in a program. If programmers want the "freedom" to deal with
> uninitialized variables, invalid subscripts, invalid parameters and so
> forth, there are already many other programming languages available to meet
> those needs.
>
> >[Namespace]
> >
> >I think there is general agreement, especially by those who have tried
> using
> >multiple libraries. The problem even occurs with using named indexes in
> >sequences:
> >
> > window[POSITION]
> > political[POSITION]
> >
> >This whole namespace problem seems to beg for implementing classes. After
> >all, we're trying to use the same names to accomplish different results -
> >the very definition polymorphism.
> >
> >Obviously, there is no trivial fix for this. I had investigated putting
> >together a pre-processor for structures some time back, but dropped it when
> >it became apparent that because of their recursive nature, it would be
> >impossible to resolve structures until run time.
>
> 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.
>
> 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"?) :)
>
> Gabriel Boehme
