1. Welcome to the Euphoria LISTSERV
Welcome to the Euphoria LISTSERV.
Contributions are archived, and retrieveable, for all eternity!
Nothing is wasted or forgotten.
Robert
there is some information that should be kept in the archives:
How did Euphoria come to be?
Is it based on another work?
Was it written entirely by R.C.?
What language was it written in, how many source lines?
Will it be ported to other platforms?
Are specs being developed for Version 2?
Will we be able to extend it?
John
2. Re: Welcome to the Euphoria LISTSERV
On June 21, John Kinne wrote:
> How did Euphoria come to be?
> Is it based on another work?
> Was it written entirely by R.C.?
Back in 1989 my brother Dave, who is also a software developer, bought
an Atari Mega ST with a whopping 4 Mb of memory. I was very impressed
and I wanted one too, but I didn't know how to justify buying one.
I decided I would do some kind of long term hobby project in the compiler
development
area, since that is what my background is. After several months of day dreaming
I finally decided -- I would design and implement a new programming language
loosely based on my Master's thesis at the University of Toronto.
In my Master's research I had examined John Backus' FP language. John Backus
is the guy who developed the first Fortran compiler for IBM.
Euphoria (it didn't have a name back then - just language 'X') took the
concept of atoms and sequences from FP, but is totally different in all other
respects. Also, in FP an atom can be a number or a string. I didn't like
that. I thought a string should be a sequence of characters, so you could
apply subscripting, appending etc. to it, just like all other sequences.
The idea of slicing came from Ada.
Within a few months I had a working prototype interpreter for Euphoria.
I had designed it as best I could for maximum speed. I eagerly performed
the first sieve benchmark test -- Euphoria was 250 times *slower* than C on the
Atari. I was not particularly disappointed. I thought a Euphoria interpreter
*should* be tremendously slower than compiled, optimized C code, given all the
flexibility, garbage collection, subscript checking etc.
Over the next 3 years I continued to add to the language and to improve the
speed.
Speed became something of an obsession for me. On at least 3 occasions I
completely
re-wrote thousands of lines of the interpreter, just to get a modest boost
in performance.
My full-time day job was getting very boring at the same time that Euphoria
was getting more interesting. Finally a good opportunity arose and I quit my day
job so I could port Euphoria to the IBM PC, finish v1.0, and release it as
shareware.
Since then I've been pleased with the reaction to it, and although there isn't
a lot of money in it, the registration rate is steadily increasing.
I'm doing some consulting work now to pay the bills but I'm as busy as ever on
Euphoria (I never sleep).
My wife, Junko Miura, left her job as a compiler developer
a few months ago, so she could persue other interests, including Euphoria.
To avoid any conflict of interest accusations, she carefully avoided doing any
development work on Euphoria until now.
> What language was it written in, how many source lines?
Euphoria (ex.exe) is written in WATCOM C/32. It consists of just 14,000 lines.
(about the same as the number of lines of Euphoria code in EUPHOR14.ZIP)
There's also a bit of machine code for added performance.
> Will it be ported to other platforms?
I hope so. I could release the source in some manner. I haven't
decided yet.
> Are specs being developed for Version 2?
I've got wish lists with dozens of ideas for improving things.
I usually need a couple of months after a release to settle
on the major features for the next release.
> Will we be able to extend it?
I'm investigating the possiblity of dynamic link libraries where
Euphoria code could call C subroutines. Nothing is certain yet.
> I am developing a program that will be widely distributed.
> If the interpreter(?) discovers an error, it displays an error
> message telling the user that the source program is over 300 lines
Someone else brought this up just before v1.4 was released, so I didn't
have time to deal with it. I think what I'll do unless someone can
suggest a better idea, is to add a library routine that you can
call that will establish the message to be displayed if a run-time
error occurs. This would be done for v1.4a which might be out in a few
weeks or so. You might call this routine more than once in your program
if (say) you want to change the message based on your program having completed
at least part of it's task. This routine may be helpful to those who are
over 300 statements but are trying to avoid registering, but that's ok I guess
-----------------------------
Rob Craig
Rapid Deployment Software
-----------------------------
