CLHS: Issue FUNCTION-TYPE-KEY-NAME Writeup

#

## Issue FUNCTION-TYPE-KEY-NAME Writeup

    Issue:         FUNCTION-TYPE-KEY-NAME
    References:    CLtL p.47-48, 61
    Category:      CLARIFICATION, CHANGE
    Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
                   Version 2, 15-Jan-1988 Sandra Loosemore
    	           (from comments by Kent Pitman)
                   Version 3, 13-Feb-88 Masinter
    Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT,
                    KEYWORD-ARGUMENT-NAME-PACKAGE
                    FUNCTION-ARGUMENT-TYPE-SEMANTICS

    Problem description:

    The FUNCTION type specifier list is provided to allow declaration of function
    argument types and return value types.  This type specifier uses a syntax
    similar to the usual lambda list syntax to specify which types go with which
    lambda list variables.  However, there is a problem with &KEY lambda variables
    because CLtL does not specify how the types specified in the FUNCTION
    declaration are matched up to either the actual arguments passed to the
    function, or the lambda variables in the function definition (since the ordering
    of keyword arguments is arbitrary).

    Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):

    (1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list
    should be supplied as lists of the form (<keyword> <type>).  The <keyword> must
    be a valid keyword-name symbol as must be supplied in the actual arguments of a
    call. (This is usually a symbol in the keyword package, but, as per
    KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.)

    (2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list.

    The interpretation of such declarations is that, when &KEY is given in a
    FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given
    are exhaustive unless &ALLOW-OTHER-KEYS is present.

    &ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be
    supplied and, if supplied, may be used.

    Example:

    The type of the function MAKE-LIST could be declared as:

       (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)

    Rationale:

    (1) This specifies a direct correspondence between the argument type and its
    matching keyword.  All of the information is in one place, and the user does not
    have to remember (or even know) the order in which &KEY arguments appear in the
    actual function definition.

    (2) This is probably an oversight in the original specification.

    Current practice:

    Many Common Lisp implementations currently ignore FUNCTION type declarations.
    The situation regarding type specifications for keyword arguments is so
    ambiguous that few users attempt to use them.

    Cost to Implementors:

    Implementations that ignore the FUNCTION type specifier or keyword arguments in
    a FUNCTION type specifier may continue to do so.  This proposal should not
    involve massive amounts of code to be rewritten.

    Cost to users:

    Because the current situation is so ambiguous, FUNCTION type specifiers and
    particularly the specification of keyword argument types are not widely used.
    However, since this is an incompatible change, it would be nice if
    implementations check for, and warn about, old-style usage.

    Cost of non-adoption:

    If nothing is done, the FUNCTION type specifier will continue to be of limited
    use for its intended purpose.

    Benefits:

    Adopting the proposal will clear up an area of confusion in the language design.

    Esthetics:

    The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
    lambda list syntax.

    Discussion:

    The exact semantics of function declarations and the types of arguments  is
    still under discussion, as are several other issues dealing with declarations.
    However, this issue seemed separable.

Copyright 1996-2001, Xanalys Inc. All rights reserved.