[r6rs-discuss] Counter-proposal (Re: Proposed features for small Scheme, part 9: modules)
kumoyuki at gmail.com
Wed Oct 14 13:30:00 EDT 2009
2009/10/14 Aaron W. Hsu <arcfide at sacrideo.us>:
> On Wed, 14 Oct 2009 10:51:42 -0400, David Rush <kumoyuki at gmail.com> wrote:
>> I am starting to suspect that the only truly correct way to move
>> forward on macro modularity is to rebase the notion of a Scheme system
>> as a purely interpreted textual language.
> You seem to be arguing:
> 1. Module systems shouldn't need to be anything more than Lambda and
jumping ahead of me on that "should", but I definitely lean in that direction.
> 2. Macros can not be modularized with lambda and load.
Macros are a whole other kettle of fish which I will say a couple of
things about in the sequel.
> 3. Ergo, we should get rid of Scheme as we know it.
Macros (up to R5RS) were always been a poorly-standardized hack glued
on to Scheme. SYNTAX-RULES was well-standardized, but it is
essentially a separate Turing complete language glued on to the side
of Scheme. R6RS standardized SYNTAX-CASE which brings in a whole lot
of problems. Judging from the questions I have seen on c.l.s and
elsewhere, there is a very complex and opaque computational model that
you have to keep in mind when modularizing macros. This seems to me
like it got rid of Scheme as we know it, so - assuming I actually
advocated "getting rid of Scheme as we know it" (I did not), I'm not
entirely sure what you are finding fault with.
W/rt to hygiene-breaking macros: there is a sense where, through
modularizing them, you are essentially trying to create a closure over
the state of the compiler itself. That is really a non-trivial
exercise, and while I applaud the efforts of Matthew Flatt (did I
remember correctly) in writing _You Want It When?_, I am less than
convinced that separating the compilation into phases does much more
than improve the clarity with which we see the problem. I don;t think
it automatically translates into the R6RS solution to modularization.
So if we're going to close over the compiler *anyway*, why NOT view
compilation as a partial evaluation of the interpreter with the
program as input? Especially if we get a simpler evaluation model and
a clear notion of the semantics? I know I have seen some papers
suggestive of (if not outright advocating) this approach.
suspect != ergo
More information about the r6rs-discuss