Issue: FUNCTION-TYPE-KEY-NAME

[sandra%orion@cs.utah.edu (Sandra J Loosemore)]

Issue:         FUNCTION-TYPE-KEY-NAME
References:    CLtL p.47-48, 61
Category:      CLARIFICATION, CHANGE
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT


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 keyword arguments may be specified in arbitrary
order in both the the lambda list and the actual argument list.  It is not
possible to match up the types specified in the FUNCTION declaration to
either actual arguments or lambda variables without additional information.


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 symbol in the keyword package.

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


Test Case:

The type of the function SORT could be specified as:

(FUNCTION (SEQUENCE FUNCTION &KEY (:KEY FUNCTION)) SEQUENCE)


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.


Conversion Cost:

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:


-------