Finally, I would like to close this discussion.
To recapitulate: I proposed to extend SRFI 139 by adding the requirement that all R7RS keywords should become syntax-parameters.
I also gave a rationale for this: "Keywords defined by define-syntax-parameter are indistinguishable from keywords defined by define-syntax as long as syntax-parameterize is absent, so this requirement does not change the semantic meaning of any existing code. On the other hand, being able to reparameterize built-in keywords can make a lot of sense. One natural candidate is quasiquote, whose name is tied to the reader. The extra requirement would make it possible to give quasiquote a different (or extended meaning) in well-defined lexical scopes."
However, I have come to the belief that it is not a good idea to change the semantics of the R7RS keywords even when it makes no difference when syntax-parameterize is not used. The reason is quite simple:
How would the following code behave:
(import (scheme base) (srfi 139) (my-lambda))
(syntax-parameterize ((lambda (syntax-rules () ((lambda formals body) (my-lambda formals body)))
(let () (display "Hi!\n")))
If (scheme base) defines let in terms of lambda as it is in the section 7 of the R7RS, the above would expand into a macro use of my-lambda, which is assumed to be exported by (my-lambda). On the other hand, if (scheme base) implements let natively, a macro use of my-lambda would never show up.
So making all keywords syntax-parameters would expose too much of the internal workings of libraries that were not written with SRFI 139 in mind.
Thus I finally withdraw my proposal. SRFI 139 should be kept exactly as it is.
--
Marc
Okay, please submit your revised draft. If no one objects over the next week, we can consider it an erratum and publish the revised version.