chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Fix meta evaluation (so that require-exten


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Fix meta evaluation (so that require-extension-for-syntax works properly)
Date: Mon, 1 Jul 2013 21:45:38 +0200
User-agent: Mutt/1.4.2.3i

On Mon, Jul 01, 2013 at 03:20:38PM -0400, John Cowan wrote:
> Peter Bex scripsit:
> 
> > (currently all the macro environments are shared between all modules
> > and there's only one level, which means you can't import a module for
> > syntax which itself imports another module for syntax and have it see
> > a clean environment).
> 
> Does it matter?  In Racket, you can have identifiers defined differently
> at different levels, but in other R6RS systems (well, maybe not Chez, I
> don't know Chez) the only "cleanness" you actually get is that identifiers
> can be defined at some levels and not at others.

Yes, it matters.  We've been hitting our head against a brick wall trying
to implement R7RS-small's syntax-rules in the r7rs egg, which is supposed
to be imported at phase 1.

Regardless of how much R7RS-small tries to ignore phasing issues, the
right hand side of define-syntax, let-syntax etc see a different
environment from other expressions (at least in CHICKEN).  This means
that currently we can only get syntax-rules from R7RS through
(import-for-syntax r7rs), because it's on the right-hand side of
define-syntax.

If an egg imports syntax-rules from R7RS, another egg that just imports
"scheme" is not supposed to "see" the R7RS extensions.  This can
(admittedly, in rare cases) cause backwards-compatibility issues when
mixing R5RS and R7RS code: R5RS syntax-rules treats _ in patterns as an
identifier to bind in the template, whereas R7RS syntax-rules discards
whatever appears there.  Any R5RS code that uses an _ in both pattern
and template will break with the R7RS syntax-rules, so it's rather
important that the two environments are separated.

> In exchange for this very dubious benefit, we have a situation in
> which implementations are allowed to ignore phase information if it
> is provided, but equally allowed to insist on its presence.  (If
> conflicting definitions were allowed, obviously phasing information
> would have to be explicit, as it is in Racket.)

You can't truly ignore it, except maybe by hacking around it by making
syntax-rules a part of define-syntax and friends, and allowing no
other macro expander types.

I suppose perhaps you *could* ignore phasing by letting IMPORT act on
the environment at all levels, but that would fundamentally break
CHICKEN's separate compilation model, IIUC.

I've been trying to figure out how Chibi does this, but I so far have
been unable to load even the most basic module definition.  Has this
not been implemented fully yet?

> I hope that in R7RS-large we are going to do without phasing declarations
> and force the implementation to either put everything in one big phase
> (and so what if some identifiers are defined when they are not needed)
> or figure out the phases itself based on the library dependency graph.

I've been mulling over the idea of an "export-for-syntax".  Felix hates
it, but I think this might mirror import-for-syntax and solve the problem
at level n and n+1.  This will make (import r7rs) import syntax-rules at
the correct level, without the user having to explicitly type
(import-for-syntax r7rs), like they have to do now.

If you need more levels, you can reach it through (import-for-syntax X),
and have (import-for-syntax Y) in X.  That way, Y will strictly speaking
be loaded at level n+2.  However, though this is simple, it's also hacky
when the user really needs to define something at a different level
within one module, and I have no idea what would happen in a let-syntax
nested in a let-syntax.

As much as I hate to say it, the explicit phasing stuff in R6RS really
seems like the Right Way to do it.  It's ugly, so perhaps the syntax
could be improved upon.  ie, something like
(import (for-syntax (for-syntax X)))
could import X at level n+2.  OTOH, that's ugly as hell too.  Maybe
there simply is no elegant solution for this.

Sorry for rambling!

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

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