guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]