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