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 Thu, 27 Mar 2008, David Van Horn wrote:So it seems perfectly reasonable to specify that SRFI 42 qualifier names are matched based on symbolic equality and that the SRFI 42 library does not export bindings for qualifier names.That is possible, but in my opinion not desirable. It would clash with the treatment of keywords everywhere else in R5RS and R6RS Scheme, and therefore with the expectations of users. It would gratuitously require non-hygienic macros beyond syntax-rules for its implementation. Also, one would lose the ability to exclude a subset of keywords to obtain a restricted sublanguage of the little language for use in teaching a class, and one would lose the ability to translate the little language to Japanese by import renaming.
The little qualifier language of SRFI 42 is, in my mind, a (symbolic) language apart from Scheme. Thinking of it as being built out of Scheme bindings is a poor fit, conceptually.
It does not require non-hygienic macros. If it did, this would violate SRFI 42's specification.
The implementation may gratuitously require a non-syntax-rules implementation, but the macro does not use datum->syntax, which is sufficient to be "hygienic" according to:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-12.html#node_sec_9.2(That syntax-rules cannot define this hygienic macro, as Taylor pointed out, is a problem with syntax-rules---not these kinds of languages.)
Going by the hygiene conditions in the literature, which are stated in terms of variable references and bindings, the conditions are vacuously true here because there are no variable references (it is not Scheme).
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.
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)As you point out: one doesn't have the ability to exclude a subset of keywords to obtain a restricted sublanguage of the endianness little language (because it isn't defined in terms of "keywords" in the technical sense of R6RS). The Japanese students will be up a creek without a paddle, and the old-timers will be shocked when:
(let ((big 0)) (endianness big)) ;=> bigBut translation-via-renaming wouldn't get you very far anyway. What about the strings and symbols and other data, comments, filenames, etc.? What about library, import, export, rename, big, little, etc.? A program is more than the sum of its identifiers.
And I don't think the restricted-languages-via-renaming gets you very far, either. You couldn't, for example, restrict your language to have only unary lambda via renaming (or no named let, or conds always with else clauses, etc.). Instead you would define a macro that accepted the restricted form. Likewise, for eager comprehensions or endianness.
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.
DavidPS Taylor brought up the example of case and else, but after re-reading the R6RS description of case, I don't see why else has to be matched as an identifier; the report doesn't refer to else as a keyword. Did I miss this somewhere?