🚀 go-pugleaf

rsanders@mindspring.com (Robert Sanders) writes:

>I've used several of those counterexamples.  GCL, a lisp to C compiler, 
>outruns CLISP's byte-code interpreter.  ECoLisp, another lisp to C compiler,
>outperforms CLISP by a factor of 6, and CLiCC outperforms CLISP by a factor
>of 3-4.  Camloo compiles Caml Light into Scheme, which is then compiled
>by bigloo into C, and outruns the Caml Light byte-code interpreter by
>a large margin.

My understanding is that the medium term plan is to rely on SCM's
fast interpreter.  Emprically, the penalty will be approximately like
fast byte-compiled implementations like CLISP.

It is a convincing approach:  small, no need for bytecode files and 
adequate performance for most applications.  From the task list, 
it sounds like all the performance critical stuff like regexps will
have special support (e.g. dynamically loaded lexers).  

Later it would be nice to have a compiler that could produce a portable
intermediate representation.  But this is a separate issue.

There is nothing inherent about translating from Rush -> Scheme or
Scheme -> C or an IR -> C or whatever that will make GEL slow.

The plan is sound!  Christiansen, let it go.  :-)