Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)

[masinter.pa@Xerox.COM]

This issue was apparently argued at the last two meetings. I don't think it
is very important. People are hung up in the LIST-TYPE-SPECIFIER issue, and
I think I should this should be voted on second, after we get done with
LIST-TYPE-SPECIFIER. (I'll make sure LIST-TYPE-SPECIFIER includes a forward
reference.)


!
Issue:         FUNCTION-TYPE-REST-LIST-ELEMENT
References:    CLtL p. 27, 47-48, 61
               "Artifical Intelligence Programming", Charniak et. al.
               X3J13/86-003 (A:>GLS>clarifications.text.4)
Category:      CLARIFICATION, ADDITION
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
               Version 2, 15-Jan-1988 Sandra Loosemore
	           (incorporate comments from Scott Fahlman & others)
               Version 3, 13-Feb-88 Masinter
               Version 4,  2-Oct-88 Masinter (update references,
discussion)
Related issues: FUNCTION-TYPE-KEY-NAME, 
                FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
                REST-LIST-ALLOCATION

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, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.

There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST.  For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.  

CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.

Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):

Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.

Example:

The type of the function + would be specified as:

(FUNCTION (&REST NUMBER) NUMBER)

Rationale:

This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.

Current practice:

There does not appear to be any concensus on this issue.  Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier may continue to do
so.  Probably only a small amount of code would have to be written/changed
in implementations that currently think that the  &REST argument should be
LIST.

Cost to Users:

Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code.  However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.

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:

Debatable.  One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.

Discussion:

This issue provoked considerable debate in the cleanup committee and at
X3J13. It seems like a vote on LIST-TYPE-SPECIFIER would help clarify some
of the issues; if there is a LIST type specifier, there would be more
support for the alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the
LIST type to allow declarations of the form, e.g., (LIST NUMBER).
 
Those who favor USE-ACTUAL-ARGUMENT-TYPE argue that the simplicity of the
declarations and the ugliness of the alternative, as well as the weight of
current practice, argue for it. 

Kent Pitman has argued against this proposal on the following grounds:

``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.

``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language
where it might be useful to declare a sequence type.

``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated
explicitly (if it is not already in CLtL somewhere) that the following is
illegal:

 (DEFUN FOO (&REST X) X)
 (APPLY #'FOO T)

since there will be no way to type-declare this. Even though this is an
obscure case (that doesn't even work in some implementations), it's the
sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''