I urge you, therefore, to decide in favor of procedures once and for all. Another SRFI can be written to generate macros.
### R7RS-large and hygienic keywords
I urge you to declare hygienic keywords out of scope for this SRFI.
* However, no RnRS report has keyword objects yet so standard Scheme
reads :e as an ordinary identifier. It would be nice to preserve this
simplicity in the standard, and add an alternative syntax for keyword
objects. Kawa, Guile and Racket already have #:e.
From an R7RS-large perspective it is not possible to make :e not an identifier, as compatibility with R7RS-small must be preserved.
If the final syntax of SRFI 177 (or any future SRFI for keyword objects to be included into R7RS-large) still has to make a distinction between identifiers starting (or ending) with a ":" and identifiers that do no, R7RS-large shall weaken the requirement of R7RS-small that :XXX (or XXX:) has to be an identifier.
Otherwise, we would be adding a big and ugly wart into the language. I *urge* you not to do this.
It is possible to add #:e as a new lexical syntax, but I am not going to add anything to R7RS-large that *depends* on the existence of a new lexical syntax. At the end of the process, we will consider convenience lexical syntaxes, like #2a((1 2 3) (4 5 6) (7 8 9)) for arrays (there are alternatives).
* Since SRFI 177's main goal is compatibility with existing Scheme
keyword systems, it will use the syntax (call/kw foo 1 2 :d 3 :e 4).
Good. CL uses leading colons, they are lexically valid everywhere (as keywords or symbols), and I urge you to choose this format.
### More complex keyword specifications
SRFI 177 is meant to be the simplest thing that could work.
Good. You can always make hair shorter by cutting it. You can't make it longer except by waiting.
It would probably be wise for R7RS-large as well, but I'll leave that decision to others.'
People will either vote SRFI 177 in or they won't. I'll schedule it for the Amber Docket (the first docket of syntax forms, which contains the ones that are already SRFIs.)
As soon as SRFIs (for inclusion into R7RS-large) are written that depend on SRFI 177, there won't be much of a free choice anymore without seriously hampering the R7RS-large process.
Furthermore, so far the process of creating R7RS-large has shown that there is almost no technical discussion during the voting period and the voting results can be slightly random depending on who is participating, so I think that we have to reach a consensus first.
Thus, I urge you to try it.
So far, the only thing where no consensus has been reached prior the voting process are the string libraries SRFI 135/140/???, I think, and, at least to me, the situation with strings is still a bit messy.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgAnd it was said that ever after, if any man looked in that Stone,
unless he had a great strength of will to turn it to other purpose,
he saw only two aged hands withering in flame. --"The Pyre of Denethor"