Re: let's bytecode it!

[Ludovic Courtès]

Hi Mikael,

"Mikael Djurfeldt" <address@hidden> writes:

> [Jumping in again although I shouldn't since I don't normally follow
> activity on the list.]

Well, it's good to have insight from those who where there at the time,
as Andy pointed out.  ;-)

> I might be missing something, but I think Andy's idea of putting
> guile-vm in the core is obviously the right thing to do.

Guile-VM has a compiler, which compiles s-exps to GHIL, then to GLIL,
then to actual bytecode.  At each stage, it could implement smart
optimizations (although it doesn't currently ;-)).

Conversely, the interpreter has to be kept simple and above all, it has
to do as many things as possible lazily (like variable lookup,
"memoization", etc.).

Running a compile-run cycle each time the user wants to interpret code
is going to be pretty slow (at least the startup time), because you'd
end up going through a potentially slow compile cycle for each sexp.

And IMO we don't want to completely do away with the interpreter in
Guile, because an interpreter has some practical virtues too.  What I'd
envision is to have an interpreter in core Guile, and a compiler/VM *in
addition* (which could eventually be part of core Guile, but may not be
a replacement for the interpreter).

> Even though other properties of Guile *should* be reasons for people
> to use Guile, I'm personally convinced that people take the
> slugishness as a sign of poor code and think this is the major reason
> why Guile hasn't been adopted to an extent several magnitudes more
> than currently.

Yes, and to be honest, many schemers make fun of this:

  A "pure" interpreter, on the other hand, does none of this business
  prior to evaluation (it just interprets source-level s- expressions;
  plain and simple).  I'm actually surprised to see this used in
  anything other than a homework assignment for junior-level course on
  programming languages.

  http://lists.r6rs.org/pipermail/r6rs-discuss/2007-March/001819.html

Not to mention what those who actually looked at the C code say...  ;-)

> But if this seems too futuristic, just replacing the sluggish
> evaluator with the vm would give Guile a major boost.  Be sure to test
> it against code using threads, though...

For the interpreter itself, if we are to keep it in addition to the
compiler/VM, I had in mind an incremental rewriting in a subset of
Scheme then compiled to C, which would make it more tractable, and
possibly allow us to optimize it more easily.  But this too is a bit
futuristic...

Thanks,
Ludovic.