vm status update

From:

Andy Wingo

Subject:

vm status update

Date:

Fri, 06 Mar 2009 20:52:42 +0100

User-agent:

Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)

Gentlemen, ladies: so long the hack, and so short the time. But the
Creator in her wisdom or absence has given us this moment in which to
ponder the novelties of the VM branch.
Since we last rapped together, let's see:
* One Sunday, I decided that we couldn't honestly claim to have a
multilingual environment without actually implementing other
languages. So I wrote a JavaScript tokenizer, a parser, a compiler
to GHIL, and a runtime -- a week later, it was working! I wrote more
about it here:
http://wingolog.org/archives/2009/02/22/ecmascript-for-guile
* Ludovic fixed loading of large unsigned integers, and added a -o
option to the compiler, and coalesced the Makefiles in to just one
in module/. My -j8 machine at work compiles much faster now ;)
* I've started to think about optimization, and what's clear is that
GHIL as it stands is too much of a pain in the ass -- you can't turn
a ((lambda ...) ...) into a (let ... ...) without like 30 lines of
code. I decided that having alpha-renamed variables would eliminate
the need for <ghil-env>, and make GHIL actually readable and
writable without loss of information.
So I started looking at separating expansion + renaming from
compilation, as the Scheme lords decree, but I'm not quite there
yet. I have an expander, but we really want source information -- so
I just fixed syncase expansion to give us source information
corresponding to its output variables, but haven't yet figured how
to recover the source lexical names. But I'll get it.
Having now looked much more at syncase, I think it's pretty great. Also
given that it finally loads quickly, and gives us source information, I
want to include it at the heart of Guile -- early on in boot-9.scm. It
goes against lazy memoization, but given that expansion is fast (and
linear), that shouldn't be a big problem. We'll see how that goes.
Syncase + GHIL without <ghil-env> also gives us the opportunity to
simplify GHIL itself, removing e.g. quasiquote in favor of syncase's
expansion. That can let us simplify the evaluator too. The interpreter
could even become threadsafe, eventually.
Anyway, that's where I am. Bug-wise we still have a bug in backtraces,
which I need to pin down at some point, and update docs -- but generally
speaking we're mergeable. What do people think, should I be working on
master at some point?
Cheers,
Andy
--
http://wingolog.org/