>> 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. > > https://www.cs.utah.edu/plt/publications/scheme09-fb.pdf explains the > motivations. Note that "PLT Scheme" means Racket. Nice, thanks. I never grokked the difference between PLT Scheme and MzScheme. Was PLT the distribution and Mz its VM? DrScheme was the IDE. > 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. That's right, each procedure will stick to one style. I meant that when you have many procedures from many libraries, they are going to mix and match alists, plists, records, etc; you have to memorize things and you get no support from tools. Keyword args offer a "blessed" way to do it, with standard syntax and semantics, and optional optimizations and read syntax from some implementations. This also helps later with code completion, code indexing, documentation generators, etc. "Programming in the large" is nicer and works better when things are standardized. The Racket team must have a big realization about that at some point. > 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). Thanks for being a stickler for hygiene. I rewrote two implementations thanks to comments from you and Marc. > 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). Thanks. I still don't truly understand why keyword args need to be blazing fast. I'll start another thread to try and ge to the core of it. > Dybvig's idea of using identifier-syntax declarations to convert foo: into > 'foo or 'foo: one at a time is interesting too. You're referring to his remarks: > SFRI 89 can be implemented at the source level along the lines of the code given in the SRFI description (although I would use symbol-hash to speed up the hashing process), and a suitable replacement for SRFI 88 in almost all cases would be to define keywords as identifier macros, e.g.: > > (define-syntax color: (identifier-syntax 'color:)) > > so that the identifier color: becomes, in effect, self-evaluating. This is actually better than having all symbols ending in colons be self-evaluating, because a misspelling is potentially caught at compile time. No strong opinion on this. Is identifier-syntax the same as a symbol macro in Common Lisp?
