This page is part of the web mail archives of SRFI 89 from before July 7th, 2015. The new archives for SRFI 89 contain all messages, not just those from before July 7th, 2015.
Marc Feeley wrote: >>I'd like to see some compelling examples that demand named parameters >>and for which alists of options would not suffice, perhaps for >>performance reasons or otherwise. In my experience I can't recall >>ever having found any good ones, really; do you have any particularly >>compelling examples where you found named parameters with this >>mechanism much more appropriate than any other mechanism, or than >>separate procedures to do different jobs? >I hate to say this but... SRFI-88 and SRFI-89 were submitted along with 2 other SRFIs >which are good cases for the use of named optional parameters: > > - Extensible hash table constructor > - Extended ports I must say that even though I use keyword args regularly, I don't think they are the be-all and end-all solution for everything. Keywords are one possible way to handle complex argument sets, it's relatively easy to implement and scales (sort of) with regard to maintenance. But care must be taken not to end up with something like Common Lisp, where there exist a small set of generic procedures with overly confusing and large sets of keyword parameters (like CLs sequence functions). We can slap a keyword-enabled interface on to everything, but that doesn't mean we should (this also applies to SRFI-76). It's a nice solution if you need something quickly, but tends to get ugly later and is less efficient than (say) wrapping parameter-sets into custom data structures or providing a multi-procedure interface. So I must say that I can understand Taylor's reservations regarding the complexity of this facility. Specifically the descriptions of the whole #!rest-before-#!key or #!rest-after-#!key thingy borders on the hilarious. Again, I use this stuff: I like quick hacks and I have to think less about API-design when using keyword args. But It's still ugly and ad-hoc, and no SRFI material for me (everything IMHO, naturally). cheers, felix