AndrevanTonder wrote:
> On Sat, 29 Mar 2008, David Van Horn wrote:
>
>> The implementation may gratuitously require a non-syntax-rules
>> implementation,
>
> However, the reference implementation of SRFI-42 is in fact expressed in
> terms of R5RS syntax-rules macros. The idea of using symbolic comparison
> is therefore in conflict with the already finalized SRFI, and changing
> this basic fact would IMO require unfinalizing it so that a new
> discussion can be reopened on this issue.

By the same reasoning, specifying that the qualifier syntax is bound as
auxiliary keywords (in the sense of R6RS) is in conflict with the
already finalized SRFI.

The premise of this SRFI is that we can come to some agreement on what
these existing SRFIs should mean in an R6RS world.

> Requiring symbolic comparison would break the existing reference
> implementation and force existing systems to discard their current
> working SRFI-42 implementations. Even worse, the library becomes
> inexpressible in existing R5RS systems or ERR5RS systems that wish to
> adopt libraries but keep syntax-rules as their only macro system.

Agreed.  I am sympathetic to this argument, and I think it is sufficient
to keep symbolic equality from being required by this SRFI.  On the
other hand, I don't think this argument justifies requiring matching
based on identifier equality and that these names to be bound as
auxiliary keywords.

>> It does not clash with R6RS as there is precedent for exactly this
>> kind of little language.  The bytevectors's endianness syntax comes to
>> mind.  The language is:
>>
>>  (endianness big)
>>  (endianness little)
>
> I think this was a terrible example of use of a new macro where QUOTE
> would have sufficed, and not only I but others protested this silliness
> in the R6RS list but were overruled.  It is IMO a bad example on which
> to base any precedents.

I agree endianness is not the most compelling thing to take as
precedent, but the bigger point is: the qualifier language of SRFI 42 is
totally distinct from Scheme.  So why are we getting tangled up
disambiguating what wasn't ambiguous to start with?  As you've pointed
out, either solution involving keyword bindings has drawbacks: it either
doesn't work in general, or it doesn't work in the usual case.

>> All of this, however, argues that this is an acceptable implementation
>> strategy for SRFI 42.  It's not clear to me that this should be *the*
>> specified behavior.  So I'm not really sure how to proceed on this issue.
>
> I think the fact that it disagrees with the finalized reference
> implementation of SRFI-42 makes symbolic comparison an unacceptable
> implementation strategy.

By this reasoning, any R6RS implementation is an unacceptable
implementation strategy.  But the reference implementation is
non-normative.  What is specified is that the macro must be hygienic and
as I've argued, with symbolic comparison it is.

>> Taylor brought up the example of case and else,
>
> R5RS/R6RS have many little languages, and one should probably follow
> their example.  I would like to point out
>
>   cond: ELSE, =>
>   case: ELSE
>   syntax-rules: ..., _
>   syntax-case:  ..., _
>   define-record-type: FIELDS, MUTABLE, IMMUTABLE, PARENT, PROTOCOL,
>                       SEALED, OPAQUE, NOGENERATIVE, PARENT-RTD
>   guard: ELSE, =>
>   quasiquote:  unquote, unquote-splicing
>   quasisyntax: unsyntax, unsyntax-splicing
>   identifier-syntax: set!
>
> None of these allow symbolic comparison as an implementation strategy.

Some of these are clearly marked as auxiliary syntax, and for those, I
agree.  Some of them are not, and for those, I don't see where in R6RS
it prohibits this strategy.

I still think that symbolic equality is a possible implementation
strategy for SRFI 42.  However, it probably should not be *the*
implementation strategy.  But I think the same goes for an
identifier-based implementation.  So I am left with the inclination that
this SRFI shouldn't specify either.  This makes writing portable code
that uses SRFI 42 difficult, but perhaps the issue is best left to
resolution in a later SRFI devoted to eager comprehensions in
R6RS-compatible Schemes.

David