1. Euphoria is an Interpreter
- Posted by kenneth Oct 22, 2012
- 1361 views
Before we get too emotional about which compiler to use, remember that Euphoria is an interpreter. Very few programs need to be compiled and none need the bloat that comes with compilation. The vast majority of Euphoria users program to solve problems instead of to sell programs. We the Euphoria interpreter because of it's speed and debugging simplicity. We also program in C and perhaps other languages when it suits us. Rob's intent was to make Euphoria a better language and interpreter than Basic and he succeeded admirably.
2. Re: Euphoria is an Interpreter
- Posted by EUWX Oct 22, 2012
- 1315 views
Before we get too emotional about which compiler to use, remember that Euphoria is an interpreter. Very few programs need to be compiled and none need the bloat that comes with compilation. The vast majority of Euphoria users program to solve problems instead of to sell programs. We the Euphoria interpreter because of it's speed and debugging simplicity. We also program in C and perhaps other languages when it suits us. Rob's intent was to make Euphoria a better language and interpreter than Basic and he succeeded admirably.
Very nicely summarized.
However, there seems to be a feeling that a compiled executable for limited distribution and perhaps sale is very desirable and easy-to-acheive objective.
3. Re: Euphoria is an Interpreter
- Posted by mattlewis (admin) Oct 22, 2012
- 1363 views
Before we get too emotional about which compiler to use, remember that Euphoria is an interpreter. Very few programs need to be compiled and none need the bloat that comes with compilation. The vast majority of Euphoria users program to solve problems instead of to sell programs. We the Euphoria interpreter because of it's speed and debugging simplicity. We also program in C and perhaps other languages when it suits us. Rob's intent was to make Euphoria a better language and interpreter than Basic and he succeeded admirably.
I disagree with the statement, "Euphoria is an Interpreter." This is a bit pedantic, but "euphoria" by itself is simply a specification of a programming language. There are a few implementations, but the most popular (I believe) are the old RDS and the OpenEuphoria versions that are derived from RDS. Both of these have an interpreter and a translator.
I often translate my programs. It depends on the application, of course. A simple text manipulation probably never gets translated...it's a one off that gets discarded. This website is powered by a translated euphoria program, for instance. Even the euphoria interpreter is partly translated euphoria code!
Now, I'm going to speak from the perspective of someone who hacks on the implementation of euphoria itself. The choice of compiler is very important. The build process is dependent on the translator and the backend, which is currently implemented in C. We've experimented with serval build systems (cmake, bakefile, scons) to try to get away from compiler specific build systems, but "native" makefiles have so far been better suited for our needs.
In particular, we have to maintain separate makefiles for gcc and watcom. We've been able to use the same GNU makefile for all operating systems. Of course, making it portable is more difficult than not, but it's a lot easier than keeping mulitple build systems synchronized.
All of this trickles down to the translator, too. It's not just the code itself (and sometimes there are big differences in the way compilers do things), but the way we interact with the compiler. With 64-bit support, we now need to provide extra runtime libraries to allow for translating to dlls. So the maintenance burden is getting more difficult.
All that said, I'm actually in favor of keeping Watcom. While its future is limited to 32-bits, it's still a good compiler that has served euphoria very well, and that a lot of euphoria programmers have installed, etc. But then, my main operating system is now Linux, and I'm not terribly interested in spending a lot of time maintaining support for Watcom.
Matt
4. Re: Euphoria is an Interpreter
- Posted by DerekParnell (admin) Oct 22, 2012
- 1337 views
Before we get too emotional about which compiler to use, remember that Euphoria is an interpreter. Very few programs need to be compiled and none need the bloat that comes with compilation. The vast majority of Euphoria users program to solve problems instead of to sell programs. We the Euphoria interpreter because of it's speed and debugging simplicity. We also program in C and perhaps other languages when it suits us. Rob's intent was to make Euphoria a better language and interpreter than Basic and he succeeded admirably.
Well ... kinda ...
Euphoria is a programming language whose main implementations are interpreters.
I'm sure you are aware that the Euphoria interpreter is an executable program (eui.exe in Windows and eui in UNIX), but you may not be aware that this interpreter has large portions of it written in Euphoria itself. Those portions are put through the Euphoria-to-C translator and then linked with the other portions (written in C) to form the executable file. This means that the choice of compliers is a very pertinent topic for discussion because it has a direct bearing on the quality and usefulness of the Euphoria interpreter.
The main problems with Watcom are ...
- that it does not currently, or in the foreseeable future, support 64-bit CPU architectures, which are now commonplace. It does support 64-bit integers but not in native CPU form. They are emulated using 32-bit registers. It does not support 64-bit addressing.
- it does not support the newer versions of the C programming standard (see Version 2.0 and C99 Compliance)
- it is not being developed under a frequent release policy (thus updates and bug fixes are slow to arrive). The latest release is currently June 2010.
5. Re: Euphoria is an Interpreter
- Posted by Raul Oct 22, 2012
- 1301 views
I really like the capability that provides OpenEuphoria of translating code to C to compile it. Why not? Perl has also a C translator if I remember. Please, keep on the good work! 
cheers
