[Top][All Lists]

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

Re: [Chicken-users] google summer of code

From: Alex Shinn
Subject: Re: [Chicken-users] google summer of code
Date: Fri, 07 Mar 2008 12:24:51 +0900
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (darwin)

>>>>> "Alaric" == Alaric Snell-Pym <address@hidden> writes:

    Alaric> I'm also keen on a proper library/module system,
    Alaric> though. I'd like to be able to use multiple
    Alaric> macro systems in the same source file, for a
    Alaric> start. So something where chicken itself has a
    Alaric> notion of a macro environment, and macro systems
    Alaric> just register closures in an alist or whatever
    Alaric> that (define-syntax ...) dispatches on to
    Alaric> convert whatever the user supplies into a
    Alaric> closure that rewrites syntax objects, then when
    Alaric> the macro is invoked, that closure can be
    Alaric> applied to perform the rewrite. Then the module
    Alaric> system needs to know that there are two
    Alaric> environments - values and syntax - to expose
    Alaric> from modules and import into places, and all
    Alaric> should be well. Surely?

Actually, that would be far more work than I'd be interested
in.  The different macro systems all have their own
representations of hygiene information, and getting them all
to work together would be a pain.

What I would probably end up doing is choosing a single
macro system to be required for the module system.  Probably
riaxpander because Taylor Campbell will actively support it
and it already handles syntax-rules, syntactic-closures and
explicit renaming.  Implementing syntax-case on top of it
wouldn't be much work either if people really, honestly felt
they wanted that (except identifier-syntax - it would be
easy enough for someone else to add but I couldn't bring
myself to dirty the macro semantics so badly).

Though if people want syntax-case I'd like some rationale
before working on it, and clear reasons as to why they don't
like the more straightforward alternatives.

Again, interoperability with non-module eggs is an important
goal, so this wouldn't affect any existing eggs.


reply via email to

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