AndrevanTonder wrote:
> 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))
;=> big

But 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.

David

PS 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?