I have taken a look at your
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/FilesAdvancedCowan.md.
I hope this is what you have had in mind.
That's out of date, but for the discussion of principles it's just fine.
The "settings" argument is used for procedures opening files, which
are non-trivial themselves. Thus, I don't think the loss of
performance when plists are used will be noticeable in any way;
In this case I agree, but I'd like a more general solution for times when performance does matter, but we still want readable calls.
furthermore, an optimizing compiler should be able to compile it
efficiently when the called procedure is known at the call site.
As many procedures share the same settings argument, a better
solution, though, seems to be to define an opaque "settings" type.
That seems to be about what R6RS does. I'll take another look at it.
I was referring to the idea that the main advantage of keyword
arguments is that parameters can be added to API calls in a
backward-compatible way.
I think the main advantage is readability. You can just as well add ordinary unnamed arguments at the end of an ordinary lambda-list, but at a high cost in readability.
So far, R7RS-large already includes a huge number of procedures. None
of these make use of keyword arguments but the solve the perceived
problem in other, not less elegant, ways. Confer my example of
"set-copy" and "set-filter" in SRFI 113, for example. If R7RS-large
had had keyword arguments from the start, only "set-copy" would have
been needed.
True, but that's linear, not combinatorial. If you want to copy doing this and then that and then that and then you're done, you need a lazy invocation framework, not keyword options.
If keyword arguments suddenly go into widespread use in the middle of
the standardization process of R7RS-large, we end up with a not very
uniform overall API of R7RS-large.
IMO, this is the first time we have needed p-lists or keywords or other such things.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThe Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture. And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein. --Gospel of Tux