[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: let's bytecode it!
Re: let's bytecode it!
Fri, 25 Apr 2008 12:11:51 +0200
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
"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,
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
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