Re: Eu To C Translator: An Inmate's Review

new topic     » goto parent     » topic index » view thread      » older message » newer message

On 26 Jul 2001, at 10:37, mtsreborn_again at yahoo.com wrote:

<snippage engaged, but not documented>
 
> Now, I talked to Rob about Euphoria's future, and as I
> see I started people thinking about Eu's future on
> non-x86 platforms (as the recent threads prove), I
> have the good news that Euphoria will be Portable in
> the future, for a price, but like I was here to
> advocate such a portable Euphoria to Robert, I'm also
> here to make sure the product which he produced under
> because of my constant nagging :p sells.
> So, people, do pay for a portable Euphoria, or i'll
> kick you in the back (J/K) :p

Altho Eu may have a priority in my existance, so does food. Some of us pay 
for only what we need at the time we need it, that's all we can do.

> - The future Portable Euphoria should still come as 2
> packages, one for E2C and one for the interpreter. 

I agree, there could easily be two paths of code here, due to optomising in 
the E2C translator. The reason i say this is the possibility of calling
functions
in the interpreter directly in the future, and the interpreter needing to
enforce
types/bounds in each and every function, whereas this overhead could be 
skipped or if-else'd-out in the translator for speed and the assumption the 
programmer knows what they are doing, or at least proofed the code using 
the interpreter first.

> Or, again, atleast make it a labeled goto!

OOOOOOOOHHHH, that dreaded 4-letter word again!! hehe! smile

 
> - Doing BOTH of the above (requiring 15 minutes of
> work for Rob!), will increase overall program
> execution speeds with about 700% for programs using
> reasonable amounts of math and atleast one variable
> being used in a loop.

For graphics, yeas. I think Eu is going places Rob hadn't considered when 
he began this language. I still don't do graphics, altho i have considered a 
great little 3D app, and i could still use a .jpg/.gif overlayer/manipulator 
program in a certain http proxy application. I still dream occasionally of a 
dedicated strings handler hardware box, which uses little math compared to 
those, but still uses a mess of memory and does an equally large of garbage 
collection.

Kat

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu