[Top][All Lists]
[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.