[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Superfluous actual arguments

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 <feeley@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