[R6RS] new syntax srfi draft, reference implementation

[Michael Sperber]

dyb at cs.indiana.edu writes:

> I tried to think of a way to move forward without responding to your "bit
> of a rant", as you put it, but I haven't thought of one, so here goes. 
> I've tried to be diplomatic, but it's not easy to be diplomatic in
> responding to rants.  Please forgive me if I'm not diplomatic enough, and
> try to respond without further ranting if possible so that we can come to
> some sort of closure on this and get the syntax SRFI out the door.

You've been very diplomatic---I very much appreciate for taking all
this in good spirit, and for bearing with me.

In the interest of not dragging this on forever, I won't reply to
every bit of your email, also as I think we're in much better shape
now.

>>From the lead-in text, I expected the examples to illustrate some subtle
> issue with internal syntax definitions, and/or some inconsistency between
> internal define-syntax and internal define.  So it's confusing that the
> only differences between the two examples involve whether the macros
> introduce a whole variable definition or just the RHS.  Given this, they
> actually seem to illustrate a subtle difference with internal *variable*
> definitions rather than with internal syntax definitions.

That's certainly also a valid viewpoint.  (And I'd be all for
addressing it if I knew how to do it in a manner acceptable to
everyone.  You may remember that way back, when Richard was still
around, this discussion included internal DEFINE.)

> Indeed, it turns out that the internal syntax definitions are essentially
> red herrings. [...]

Touche.

> I've since addressed this "bogus keyword reference" issue, incidentally,
> in the current draft of the SRFI and reference implementation.  The
> algorithm now raises an exception in cases like the second of each pair of
> examples above where a keyword referenced during the expansion of one
> definition is redefined by the same or a subsequent definition in the same
> body.  This is basically an expand-time version of the letrec*
> restruction.

Great, that helps a lot.  I'll have to meditate on it a bit, so I
reserve the right to come back on this, but I'm much happier now.  I
withdraw my objection to putting up the SRFI draft.

I can't help but comment on this bit of bait, though:

>> [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.]
>
> Many smart people think templates are great, including colleagues who work
> down the hall from me, although they acknowledge that the syntax forced on
> them by C++'s restricted syntactic abstraction facilities is terrible.

I assume you're referring to the folks down the hall who're
contributing to Boost.  I'm currently finishing a commercial project
we've done with the help of Boost, specifically its serialization
library which relies very heavily on template metaprogramming.  On
average, we (two programmers) would spend at least one person-day for
each ten person-days on debugging problems we've had because of the
subtleties of template expansion.  Most of those problems had to do
with the ordering of expansion.  I can't see how any restrictions
(especially not in the syntax---the syntax is fine) play into it.  But
it's certainly an indication that people will eventually exploit most
operational aspects of the mechanism in a way that's sensitive to the
details of its specification.

> Okay, let's do a better job nailing down what it means.  I believe that
> the syntax SRFI is already more detailed and precise than some of the
> other R6RS SRFIs, but it can certainly be improved.

I agree with Will's concern about Section 3.2, and I stand by my
comment that the SRFI should identify---at a higher level---what it
means by hygiene, how the algorithm fits that definition, and where it
breaks it

Without that, I find it hard to comment on the hygiene issue, as it's
difficult to identify why it does what it does.  By my personal notion
of hygiene (which I take from Martin Gasbichler's thesis), I find
neither the definition in the current draft nor the one in SRFI 72
compellingly hygienic.

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