This is the mail archive of the
mailing list for the Guile project.
Re: Is guile byte-code compiled?
Greg Harvey <Greg.Harvey@thezone.net> writes:
> Mikael Djurfeldt <email@example.com> writes:
> > Michael Vanier <firstname.lastname@example.org> writes:
> > > As you point out, thought BC isn't a panacea, and I'd like to
> > > understand more about the tradeoffs.
> > Since Guile is supposed to be an application scripting language you
> > don't want it to be too large. If you use BC, you need both a BC
> > compiler and a BC interpreter, which increases the size of the
> > system. (Look at Scheme48 or RScheme. They are really huge compared
> > to Guile.)
> All you need is a core with a normal code and a byte code interpreter
> (which I guess falls down to two evals... I can't see how this would
> be major bloat, given that we've got pretty much everything else under
> the sun ;). The bc can be in a separate module.
Actually, all you need is a flexible eval. If you can hook up
eval functions for different "tagged" lambda objects, you could
add a bytecode module, a native code (e.g. hobbit) module, etc.,
without any problem.
So, we could stick to the current evaluator, and just add
appropriate hooks (or similar) to the main eval function.
Then we add appropriate calls in load as well so it'll call the
right function for "totally compiled" files, or even .so files (i
think this is already in the making)
That way, we can give guile one of the good things Lisp is good
at - partly-compileable code. E.g. you have some functions which
are byte compiled, others which are "just" interpreted, and even
others which are native code compiled.
CMUCL does that already (not sure about byte compilation).
Granted, byte compilation isn't really that of a big goal if you
can compile to native code, though there might be advantages when
you can define your own VM instruction set.
> > A BC system also needs to do more work when loading code.
> You can compile everything when you load, but that's a fairly lousy
> way of going about things
Or you can compile "on demand", for example with a (compile)
Speaking of it... Traditionally in CL systems, compile took a
symbol as an argument and compiled the function in that symbols
function space. To make it more schemish, i'd propose to do it
(compile <lambda-object>) => <compiled-copy-of-lambda-object>
e.g. that compile takes an object returned by lambda, and returns
a compiled copy of that function, and that compile! compiles the
lambda object "in-place".
All in all i consider the multiple-dispatch-evaluator and
on-demand compilation to be the best solution for both a good
Scheme implementation and a scripting language.
((email . "email@example.com") (www . "http://forcix.cx/")
(irc . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))