> - Keywords being global symbols vs hygienic identifiers. > > I will believe in the need for hygienic keywords when someone demonstrates > a non-hypothetical use for them. The idea seems technically sound, but I'm also a bit skeptical that well-working social conventions can be established among library writers who do not communicate with each other. Languages like Python, Ruby and Java are better than Scheme at programming-in-the-large because as systems grow larger, social factors start to dominate technical ones. The typical Lisper doesn't like to admit it. I don't like to admit it. But it's true. As we get out of core abstractions like closures and continuations, and towards complexity-management tools like module systems, keyword arguments, package management, documentation and tooling, I think we should shift focus from mathematical purity to whatever supports efficient social customs. That being said, I don't want to block 177 from interoperating with any hygienic keyword system. Fortunately it doesn't have to. >> - 177 needs to use RnRS-portable read syntax, so we can't use keyword >> objects. That means we need to use either symbols or strings to indicate >> keyword arguments. Symbols would be the natural way to indicate hygienic >> keywords, so it'd be nice to use something else for global keywords. > > I propose this: if you really must have hygienic keywords, then in systems > without keywords, a symbol beginning with ":" is treated as global. Hmm. Could this be the best of all worlds? (keyword-call 1 2 3 :foo 4 :bar 5 :baz 6) This forbids a syntax-rules based implementation. But anyway, the macro would scan the list until it finds either: - A keyword object (in a Scheme that has such objects). - A symbol whose name starts with `:`. - A symbol whose name ends with `:`. From that point on, it would parse keyword-value pairs. The natural complement for that keyword-call syntax would be John's proposed (keyword-lambda (a b c &key foo bar baz) ...). Opinions? > If Marc's Chibi library can be made to cover Chicken, Gauche, and MIT > (which will need patches for each one), I'd say that making syntax-case a > standard is feasible. Sounds great. I'm not qualified to judge syntax-case vs ER. > I don't understand that. If a portable R7RS-large library wants to expose > procedures that have keywords (and I'd like that), then it has to use > either SRFI 177 conventions or some other conventions. I mean the library writer and the library user can use different keyword systems as long as those systems are compatible. For example I've called Gambit's native procedures that take keyword arguments using SRFI 177 keyword-call; it worked fine. This also implies that either the user or the library writer can switch to a different keyword implementation at any time, independently of each other, as long as those implementations are compatible. 177 is lowest-common-denominator so that it's compatible with anything else, and so that it can be replaced with anything else. If it's not as compatible it will fail; you just inadvertently presented a better explanation of such failure than I did :) > +1. I have carefully avoided the need for them in R7RS-large so far, but > SRFIs and pre-SRFIs are now starting to appear that simply have too many > options to be handled as standard Scheme arguments. That's generally a good indication that a solution is called for. Another good case: go to the Common Lisp spec and imagine what some of the built-in procedures would look like if you take out the keyword arguments.
