OpenEuphoria

Re: Version 2.4 and beyond

• Posted by euman at bellsouth.net Feb 13, 2002
• 511 views

----- Original Message ----- 
From: "Robert Craig" <rds at RapidEuphoria.com>
> 

<snip......some>

> 2. Libraries
> 
> One of the great strengths of Euphoria, compared to
> Python, Perl, or other interpreted languages, is that
> that the standard libraries, and most other 
> important add-on libraries, Win32Lib etc., 
> are all (heaven forbid!) written in Euphoria.
> In Python they have some kludgy API that lets
> people write extensions in C, since it's obvious
> to everyone that Python itself would be far too slow.
> 
> This means that *all* Euphoria users can potentially write
> important libraries and tools, where performance matters,
> whereas in Python, you need to be a C expert and 
> a Python expert, as well as learning the strange API.
> This bodes well for the future expansion of cool things
> that you can do in Euphoria.

I always wondered why a better or faster way of doing something
is still not part of the interpreter. If 

>This means that *all* Euphoria users can potentially write
>important libraries and tools, where performance matters

this has been accomplished already shouldnt it (after extensive test)
become part of our/your language? Freeing up some time spent
making Euphorians include them...

Here are some function that make Euphoria faster
why are they not put into the interpreter?

(small list)

global function alloc_string(sequence s) -- diff but faster
atom mem
    mem = allocate(length(s) + 1)
    poke(mem, s)
    return mem       
end function

-- these are used functions that would make our code
-- shorter. I have many larger examples.

--You know things that seem to be in almost every program
--but could possibly benefit from faster inlined C Code.

global function LOWORD(atom long)
   return remainder(long,65536)
end function

global function HIWORD(atom long)
   return floor(long/65536)
end function   

--using API for most things are MUCH-MUCH faster
--than Euphoria's built-ins C Runtime counterparts

global function peek_zstring(atom lpzString)
  return mypeek({lpzString,c_func(xlstrlen,{lpzString})})
end function

I guess Im on a soapbox here about this but it is a fact Rob
that API is faster in most case than your C Runtime.

Are you planning on making Windows programmers happier?

Euman
euman at bellsouth.net