Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)

[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 Sept 1988, Walter van Roggen
	      #2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)


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.

Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers 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.


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.

This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION 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.

Cost to Implementors:

Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.

Cost to Users:

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.

Cost of Non-Adoption:

There already exists user code on many implementations that assume the
proposed semantics.  Not adopting this proposal would continue to render
such code incorrect or at least non-portable.

Benefits:

Better type checking and more compiler optimizations should be possible.

Esthetics:

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

Discussion: