guile-devel
[Top][All Lists]
Advanced

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

Re: Syntax checks


From: Marius Vollmer
Subject: Re: Syntax checks
Date: 07 Apr 2002 12:40:05 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Neil Jerram <address@hidden> writes:

> Also, does this fit into a more general picture of how we should
> evolve the interactions between transformation, evaluation,
> compilation etc.?  (I don't claim that such a picture exists, but it
> would be nicer if it did.)

I have a dimm picture of a compilation framework in my head.  Here is
what I wrote about it in a mail to Rob:

    But having a compiler for Guile is still an important goal, but we
    should do it Right rather than rush it.  I plan to attack it from
    above, by first straighten out the module system to be friendly to
    compiler semantics, redoing our current memoizer to be no longer
    tangled with the evaluator and then having a way to write memoized
    code to disk and load it back in.  Down that road are enough
    design problems that are important for good compiler support, long
    before we come close to worrying about how to produce native
    machine code (or even cross compiling).

    When we are able to write memoized code to disk and this does
    indeed speed up loading, we can make syntax-case our standard
    macro expander and the memoizer wouldn't have to work with macros
    at all.  We could then also move GOOPS even closer to the core
    [because it will load in tolerable time], using it for ports and
    the exception system, for example.  Maybe even throw out smobs.

    Then (if development is linear, which it needn't be of course), we
    can seriously think about compiling to machine code, by offering a
    choice between the memorizer and other code generators.

    [...]

    I would like to follow the path outlined above.  Hobbit would
    enter quite late, and would have to handle macros at all.  It
    would get expanded code with certain additional guarantees
    (i.e. unique variable names, correct syntax, only a few core
    forms, maybe even some special language that isn't Scheme).

    > It's not clear that full expansion at compile time is always
    > acceptable since it looks like, given Guile's current API,
    > people could have been using the macro system as a simple way to
    > write memoized code for dynamic programming, which shouldn't be
    > fully expanded at compile-time.

    I don't think we want to support that.  That practice would be
    even worse than unmotivated use of eval and instead of letting
    people get away with it, we should educate them.

    > And of course there's a whole raft of other issues related to
    > how macros and compilation should interact. i.e.

    Common Lisp will offer good hints, I guess.  This is what I want
    to iron out when separating the memoizer from the evaluator.  I
    want to make these questions 'central' to Guile, that is, the
    basic semantics of Guile are affected by this, not just the
    odd-ball compiler user.  This will ensure that compilation is
    consistent with using Guile interactively.

So I see Dirk's syntax check cleanups as steps towards a separation of
the memoizer and the executor.



reply via email to

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