Re: Is guile byte-code compiled?

[Michael Vanier <mvanier@bbb.caltech.edu>]

> Date: Sun, 23 May 1999 00:42:58 -0400
> From: Keith Wright <kwright@tiac.net>
> Cc: guile@cygnus.com
> 
> > From: Michael Vanier <mvanier@bbb.caltech.edu>
> > 
> > I'd like to know if guile is byte-code compiled, or if not, why not.
> 
> It is not.  Nobody has written a byte-compiler that is faster than
> the memoizing interpreter currently in use.  It sort of compiles as
> it goes, but not to byte codes.  
> 
> > My
> > impression is that it isn't, but I know that this isn't fundamental to lisp
> > systems (e.g. emacs lisp can be byte-compiled).  I suspect that it will be
> > difficult to match the speed of other scripting languages without some form
> > of byte-compiling.  Anyone care to enlighten me?
> 
> What's so magic about bytes?
> 

Nothing, really :-)  I'm not familiar with the term "memoizing
interpreter"; could you give me a rough overview?

> It is hard for me to believe that it is not possible for a byte code
> interpreter to run faster than the current memoizing interpretter,
> but neither is the first one you throw together guaranteed to be faster.
> 
> All the same, I like the idea of a byte code interpretter, because
> eval.c is really hard to understand.

I wonder why one was chosen over the other... was this the way SCM did
things?  I hope that guile doesn't get stuck with a sub-optimal solution if
byte-code interpretation could in principle make things faster.  As you
point out, thought BC isn't a panacea, and I'd like to understand more
about the tradeoffs.

Thanks for your input,

Mike