[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Sat, 29 Mar 2008, David Van Horn wrote:
The implementation may gratuitously require a non-syntax-rules
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
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:
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
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, =>
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
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