* From: Marc Feeley <xxxxxx@iro.umontreal.ca>
 | 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