[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Miscellanea

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.

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.

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.

is a problem with syntax-rules---not these kinds of languages.

It does not clash with R5RS, which simply did not have the vocabulary, being limited to syntax-rules, to describe these kinds of little languages.

No. As the reference implementation shows, syntax-rules has no problem with these kinds of languages. The literals list in the syntax-rules form was designed and has long been used precisely for this kind of thing.

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.

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.

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:  ..., _
  guard: ELSE, =>
  quasiquote:  unquote, unquote-splicing
  quasisyntax: unsyntax, unsyntax-splicing
  identifier-syntax: set!

None of these allow symbolic comparison as an implementation strategy.