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.
I (well, Alex was a bit quicker, actually) propose a binding form, similar to Shiver's let-optionals, that gives you everything needed to provide keyword-style interfaces to a procedure while not limiting them to one particular behaviour: [syntax] (let-keywords* <ARGLIST> ((<VARIABLE> <KEYWORD> [<DEFAULT>]) ...) BODY ...) The semantics should be obvious, for example: (define (message-box title . args) (let-keywords* args ((title 'title "<untitled>") (buttons 'buttons '(ok))) ...)) Default values are optional and default to #f (or something else). One could also imagine an optional trailing "rest" argument after the last binding to keep remaining arguments, but I think that would have to large an impact of performance, so I personally tend to leave much unspecified. Notes: - the <KEYWORD> expressions are evaluated and don't necessarily have to be keyword objects - the semantics are not as confusing as with DSSSL lambda-lists (#!key before or after #!rest ?, in what context are which variables visible?, etc.) - You have more control over the actual argument processing (how do you implement (message-box "Hello!" button: "ok" button: "cancel") with DSSSL keyword args? Seperating out the binding form gives the user the chance to implement custom behaviour) - This can be implemented on every R5RS Scheme - You don't muck with lambda-list syntax, which I think is the major problem with this SRFI (and writing definition functions for something like generic functions, or implementing alternative macro systems are just a few examples where you really appreciate this) - You can still provide keyword-based interfaces to the outside, so you get the functionality of DSSSL keywords without the warts (funny lambda list markers, fixed and complicated behaviour, unnecessary coupling to keyword objects). cheers, felix