That seems true, but there has to be a reason why Kawa and Racket both
have keywords as syntax markers instead of actual keyword objects.
> Of course, you probably should know there are going to be *some* options in
> advance, and then you go with an alist argument or plist arguments.
The problem is the "or": it soon becomes an inclusive or.
I don't understand this. Nobody will use both an alist argument and plist-style arguments, and if some procedures use one and some another, that's the way it is.
I'm obviously biased, but SRFI 177 needs only standard RnRS read syntax
while being fully compatible with all known existing native solutions.
I'm not against it at all (except unnecessary uses of define-macro).
Implementation is 20-30 lines of macros per Scheme. I find it a better
deal than thinking about alists, plists vs records for new SRFIs and
libraries. If people hate the current syntax we can find another one so
long as it's equally portable. I'd just like to have some standard that
portable code can use.
I have every sympathy with that motivation. I also have sympathy for people who will expect keyword procedures to be as fast, or nearly so, as non-keyword procedures, at least when the keywords are overt (not the value of a variable or result of a procedure).
Dybvig's idea of using identifier-syntax declarations to convert foo: into 'foo or 'foo: one at a time is interesting too.
Roda (for Ruby) is one example of a
delightful API made mostly by stacking builders on top of each other.
Each builder returns a fresh object with the changes you want instead of
mutating the object you gave.
Ah, I never thought of that. Nice!