[R6RS] new syntax srfi draft, reference implementation

[Michael Sperber]

dyb at cs.indiana.edu writes:

> Okay, I've updated the internal definition issue, but you're probably not
> going to like the result.

Indeed.

> Although I've tried to be as even handed as possible, I'm afraid
> you'll be unhappy because the resulting text doesn't support the
> conclusion you want, which is that flushing internal define-syntax
> will somehow eliminate the need to specify the expansion algorithm.

You keep putting that into my mouth, but I never said that.  (In fact,
I repeatedly said that I never said that.)  So, to be perfectly clear:
I want R6RS to specify the expansion algorithm completely and
precisely.  If my issue had been about this, I would have written so
explicitly.  Also for the record:  Whatever the issue is, I don't want
to support conclusions---I want to stimulate debate.

Now, you also completely rewrote what I had written to be about the
need to specify an expansion algorithm, including changing the
examples, which I had carefully constructed to be about something
else.  The result is actually an interesting and worthwhile writeup,
but it is not at all about what I had in mind.  Possibly I wasn't
explicit enough, so let me try again (you'll forgive me for a bit of a
rant, I hope):

I am worried about the complexity of macro expansion.  It is already
complex and subtle in R5RS, and what we've decided on for R6RS already
raises the bar significantly.  As I pointed out, adding internal
`define-syntax' doesn't really introduce completely new issues, but
new combinations of old issues with, say, shadowing.  (My original
text explicit referred to shadowing, but you deleted that.)  This
makes it much easier to write programs that expose those issues, and
are sensitive to subtle aspects of the operational behavior of macro
expansion.

Consequently, it is a legitimate question of whether the added
complexity is worth the benefit.  I haven't seen convincing (to me,
that is) examples of a significant benefit.  You claim that the added
complexity is negligible, but I disagree: I'm getting the impression
that many programs you deem simple I see as complex.  Consider that
you've been immersed in the field of macro expansion for something
like 15 years, while others are still struggling, if the volume of
email on c.l.s or the PLT mailing list on the subject is any
indication.  (It looks a lot like the traffic on "space leaks" on the
Haskell mailing list.)

Now, you've been pounding on this sentence in R5RS:

> Programming languages should be designed not by piling feature on
> top of feature, but by removing the weaknesses and restrictions that
> make additional features appear necessary.

... arguing that it effectively mandates allowing internal
`define-syntax'.  I would like to put a different spin on it: I see
the complexity of macro expansion as a weakness in the sense of that
sentence.  (It certainly makes the restriction on internal
`define-syntax' appear necessary to me.)  Yet, we've spent very little
effort on reducing or removing that weakness.  (For example, I'm
reasonably sure there are ways to address the top-level shadowing
problem with keywords.)  I'm not primarily a macrologist, and
certainly not the expert you, Matthew, or Will are, so I feel on very
unsure footing here, and you can argue rings around me on anything I'm
likely to come up with.

Your kind of argument puts us on a very slippery slope: "Just because
the problem basically exists in R5RS already, it's OK to exacerbate it
in R(5+x)RS."  My impression of the historical process is that, in
Scheme, internal `define' was added before macros---it wasn't a
problem then, just a bit of syntactic sugar.  Then macros were added,
and, because nothing was done about internal `define', the screw was
turned a bit more.  Now, the next bit for R6RS.

[Polemical aside: This is what seems to have happened to templates in
C++.  The basic idea was there, and they just kept turning the screws
in the directions they had been turned in the past.  Look what
happened.]

And while I'm on a roll here: It' not just the order expansion that
worries me.  It seems at least three different interpretations of
hygiene are possible with `syntax-case', again with subtle differences
that affect real programs.  It worries me that the description in the
current document refers to a marking algorithm, but in no way really
defines what its notion of hygiene is, or how the specification agrees
with that notion.  (As, for example, the Clinger/Rees paper does.)  In
fact, the current semantics of `syntax' seems inconsistent with the
notion as I understand it.

I don't think it'll be a catastrophe if we go ahead for R6RS, but I
thought very long and very hard about this issue over a period of many
months, and I'm still unhappy it.  So I insist on at least bringing
the issue out in the open.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla