call/kw is apply/kw:
In one sense, but I meant something like Racket's keyword-apply, which is (apply proc list-of-keywords list-of-values list-of-positional-args) and lets you decide at run time what keywords to supply.
Another thing is that passing around a keyword lambda for use as a
higher-order function is nice, even if it gets default values for all
its keyword arguments that way. It's still possible to call it with
keyword arguments from other contexts. This arrangement makes it
possible to add keyword arguments to existing procedures that are
already being used as higher-order functions. This is a good example of
the kind of situation where I want people to be able to add keyword
arguments without a lengthy and difficult analysis that "will this break
some existing code"?
Fair point.
An anonymous generic function would be like case-lambda, but casing on
argument types instead of the length of the lambda list.
No, because methods of a generic function are identified by having the same name, at least outside the MOP (I don't really know the MOP), so a gf-lambda could only have one method and might as well be an ordinary function.
> &key is standard in most Lisps and does not step on native keywords.
Stepping on native keywords in the lambda list shouldn't be a problem.
However, favoring &key because it's more standard is fine.
DSSSL and SRFI 89 use #!key, but if you want SRFI 177 in R7RS-large
after all, using something other than #!key will make it possible to
avoid mandating extra syntax in the language.
My follow-up post says any of &key, :key, or key: is fine with me, but I don't know of anything that actually uses :key or key:.
Interesting to know. Sounds similar to Kawa and Racket.
Not really: there are no keyword arguments in functions at all, only keywords in special forms.
I agree that it's unwise. I think Marc's point was more about permitting
a simple language definition without hacks than about what people should
use in practice.
The simple rule is "Don't use leading or trailing colons." Similarly, quote is a bindable identifier, but if you write (let ((quote -)) '45) you may be surprised at the result. Or not.
All the non-hideous syntaxes for mixing hygienic and non-hygienic keywords rely
on using keyword objects for non-hygienic keywords, and treating
ordinary identifiers in "keyword position" as hygienic keywords.
You could use a : prefix for standard keywords and :: or something for hygienic ones, I suppose.
If a hygienic keyword is imported, what if
you accidentally imported it from the wrong library, or need to import
conflicting keywords with the same name from two different libraries?
This last is a problem outside keywords. Before modules, you could load code that overrode existing identifiers if you wanted to, like Chicken 4 did to supply a numeric tower. I really think shadowing-import would be useful.
I feel a bit uneasy about "rushing" a new language feature in. But it's
only new in standard Scheme - the territory has been thoroughly explored
by many Scheme implementations, other Lisp dialects and other languages.
Yes, and the more familiar it looks, the better (another reason not to introduce new lexical syntax).
If there were obvious alternative, I'd advocate going slower and
checking them out. But what would those be?
I think the only thing that competes is a p-list in the rest args with explicitly quoted symbols ('e, ':e, or 'e:) and that's already portable (and slow on all implementations). Chibi's let-keywords macro packages this up in a portable way, but takes no advantage of any native keyword support. It's in the portable (chibi optional) package.
Using #f as a default for everything is extremely simple
to remember and composes naturally.
+1
I agree with your judgement, but others want them. Since these features
are all opt-in and interoperable with the simpler system, I have no a
problem with them.
Just not as part of SRFI 177. Note that Chibi has let-optionals in the same library, but they aren't meant to work together.
It doesn't have countless esoteric features like CL.
Though I am sure I will get "It's too big" complaints about R7RS-large. That is why I am using a frog-boiling/salami-slicing strategy <
https://en.wikipedia.org/wiki/Boiling_frog>. It also means that there are intermediate deliverables, unlike with R6RS.
We can only preserve Scheme's advantage if we fold incompatible
variations in language features into common subsets. R6RS and R7RS did
that admirably with module systems. We can do the same with keywords.
+1
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgIs not a patron, my Lord [Chesterfield], one who looks with unconcern
on a man struggling for life in the water, and when he has reached ground
encumbers him with help? --Samuel Johnson