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.
* From: Marc Feeley <firstname.lastname@example.org> | On 14-Apr-06, at 6:53 AM, Joo ChurlSoo wrote: >> When `#!key' does not appear in the <extended formals> and there is no <rest formal> , an error is signaled regardless of presence of `#! optional' if >> there >> are any remaining actual arguments. But When `#!key' appears in the >> <extended formals> regardless of presence of <rest formal>, an error is not signaled >> in >> spite of superfluous actual arguments. What is its rationale? | [Correction: the spec uses "it is an error", not "an error is signaled".] | This behaviour, which is from DSSSL, allows the called procedure to accept | other named parameters than the ones appearing in the formal parameter list. | Note that in this case the rest parameter will contain the list of all named | parameters (including those that do not appear in the formal parameter list). | So the called procedure can parse these explicitly or pass them on to other | procedures using an "apply". This can be useful to modularize the handling | of the named parameters in procedural layers. Each layer picks the | parameter(s) that it knows how to handle out of the parameter list, and | passes the parameter list to the next layer. This way a layer does not need | to know what the previous or next layer handles. In SRFI-89: (define (g a #!optional (b a) #!key (k (* a b))) (list a b k)) (g 3 4 k: 5 k: 6) ==> (3 4 5) In this case, there is no rest parameter. Why is this not an error? Are another k: and 6 not arguments? -- Joo ChurlSoo