Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS

[vanroggen%aitg.DEC@decwrl.dec.com]

Issue:        FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS

References:   CLtL pp 47-48, 158-159

Category:     CHANGE

Edit history: #1, 7 September 1988, Walter van Roggen


Problem description:

The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.

Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.

Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.

However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
  (FUNCTION (T T) CONS)
is also of type
  (FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.

Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.

Unlike all the other type declarations, which can be used for discrimination
and have an implicit effect on representation, specialized FUNCTION type
specifiers thus appear to have superfluous information.  By changing the
meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.

This issue does not address the use of lambda-list-keywords and
argument count matching, nor the reproclamation or additional declaration
of FUNCTION types, nor having TYPEP treat specialized FUNCTION types
as if they were just the same as the atomic FUNCTION type for purposes
of discrimination.


Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)

For specialized FUNCTION type specifiers

  (proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
  (the val-type (f (the arg0-type ...) (the arg1-type ...) ...))

If the arguments to F are of the specified types, then the result will be of
the specified type.  If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.


Rationale:

The proposal seems most like what users expect.

Current Practice:

VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner.  Many implementations don't make use of these declarations.  At least
several users make use of declarations assuming the new semantics.

Adoption Cost:

None, since making use of FUNCTION declarations is "optional".

Benefits:

Better type checking and more compiler optimizations should be possible.

Conversion Cost:

There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.

Esthetics:

This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.

Discussion: