This page is part of the web mail archives of SRFI 97 from before July 7th, 2015. The new archives for SRFI 97 contain all messages, not just those from before July 7th, 2015.
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 outcond: 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