1. C translator possibilities
Dear Rob
Language junkies like me are waiting patiently for the Euphoria to C
translator because we will then be able to have our own Euphoria doing
whatever we want with whatever language syntax we can imagine.
Think of it ... we take Dave Cuny's (?) Euphoria in Euphoria interpreter and
we turn it into C with the translator. Having compiled it, we now have a
Euphoria interpreter. Now we go back and forth extending on Dave's code
until we have our preferred implementation.
The possibilities are endless ... euCOBOL, euFORTRAN, euALGOL, euJCL,
euSPITBOL ...
oh, and by the way, what will we call the Euphoria to C translator? E2C? ECX
(like BCX)? or if the opposite of distress is eustress, is the opposite of
Euphoria Disphoria?
--
Bruce.
2. Re: C translator possibilities
----- Original Message -----
From: Bruce M. Axtens <bruce.axtens at SIL.ORG>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, May 19, 2000 1:41 AM
Subject: C translator possibilities
> Dear Rob
>
> Language junkies like me are waiting patiently for the Euphoria to C
> translator because we will then be able to have our own Euphoria doing
> whatever we want with whatever language syntax we can imagine.
....
Yes indeed!
After years of refusing to reveal any details on any of the internal
workings
of Euphoria, it seems that Rob is now going to give the game away
completely.
Why the sudden need for a compiler, when we have been told repeatedly how
fast Euphoria runs? "Almost as fast as some compiled C programs", is a
phrase
I remember.
Is this compiler project just a way to avoid fixing those problems that have
been
discussed ad nauseum in this forum? Things that stand in the way of Euphoria
being more widely used: proper namespaceing, for example. Is it really so
difficult to fix this?
Look at the number of different "OOP" implementations that have been
contributed. All show a lot of clever thinking and hard work, but they all
suffer from the same problem, they are patches and work-arounds for
functionality that should be an integral part of Euphoria. OOP is 90% there
already. The remaining 10% is something that cannot be added by third
parties.
Look at the hassles that we encounter trying to pass data to and from C
functions.
This is a problem that isn't going to go away. Why not just add native C
datatypes to the language and be done with it?
It seems to me that there have been many more requests for these kinds of
things than there have been for a compiler.
Irv
3. Re: C translator possibilities
On Fri, 19 May 2000 09:05:10 -0400, Irv Mullins <irv at ELLIJAY.COM> wrote:
>Why the sudden need for a compiler, when we have been told repeatedly how
>fast Euphoria runs? "Almost as fast as some compiled C programs", is a
>phrase
>I remember.
>
>Is this compiler project just a way to avoid fixing those problems that
have
>been
>discussed ad nauseum in this forum? Things that stand in the way of
Euphoria
>being more widely used: proper namespaceing, for example. Is it really so
>difficult to fix this?
Irv:
What ROB should have done long ago, was add a DOS extender to his
interpeter that supports DOS DLL's and let the user's add features of
their own. Then whenever someone comes up with a good idea, ROB could
move that featue into the CORE interpeter if he thought it was a good
feature. In that way if ROB didn't want to add the feature the users
could still use it by external DLL. DLL's can be used on all the other
platforms so all Rob has to do is support interpeter across the other
platforms the same way he does now. The users don't need a compiler
they just need a easy way to be able to extend the language. There
are free DOS extenders out there like WDOSX95 that support DLLs. He
says the compiler could use DOS4GW which is not free and can not be
bound into the program but is external. A compiler will have additional
cost plus bring up a cragmire of new issues like compatable object
files, linkers, as you know there is no universal compiler or linker.
Bernie
