Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues

[Ram@C.CS.CMU.EDU]

    Date: Monday, 7 December 1987  17:40-EST
    From: Masinter.pa at Xerox.COM
    To:   Ram at C.CS.CMU.EDU
    cc:   KMP at SCRC-STONY-BROOK.ARPA, cl-cleanup at SAIL.STANFORD.EDU,
	  Masinter.pa at Xerox.COM, sandra%orion at CS.UTAH.EDU
    Re:   Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues


    [...] What does (declare (function (integer integer) t) foo) imply?

    We've discussed what it could mean, what it should mean, what CLtL
    says it means, but I'd to hear about current practice. What, if
    anything, do current implementations do with such declarations? Do
    any implementations pay attention to the types of arguments in
    function declarations?

Our current compiler totally ignores function type declarations.

I am working on a new compiler that currently gives function type
declarations a strict interpretation, i.e. the function must be called
only with two integer arguments.  (I suspect that this is like the
RESTRICTIVE-FTYPE declarations that someone from Lucid mentioned.)  At
least as an interpretation for FTYPE, this is clearly wrong.  I intend
to at least rename this declaration, and perhaps entirely flush it as
a user-visible facility.

I think that we should either entirely flush the concept of "function
types" or change the theory behind them.  The CLtL interpretation is
well-defined, but not very useful.  The intuitive strict
interpretation is useful, but is not a type declaration, at least in
the sense used in CLtL.

The restrictive interpretation can be modeled as a sort of magic
syntactic shorthand for a bunch of THE declarations at the call site:
    (the t (foo (the integer x) (the integer y)))

But under this interpretation, a "function type" isn't a type at all,
since it isn't in any sense the type of the function object being
called.  It wouldn't be meaningful to declare a variable or value to
have a function type.  A "function type declaration" would be a piece
of magic recognized by the implementation that constrains calls to a
particular function variable.

If we did this, then the concept of a "function type specifier" should
be flushed, since "function types" can't be used in any of the ways
real types can.  The "function type" syntax would become part of the
syntax peculiar to a "function type declaration".  (A minor beneficial
side-effect is that it would make obvious the restriction on function
types in TYPEP.)

One problem that I have with this interpretation is that it makes the
evaluation of the functional position even more peculiar than it
already is.  Since a "function type declaration" would be purely
syntactic, it would only take effect when there was a syntactic match,
i.e. an obvious normal call to a declared function variable.  It would
probably be incorrect to do this transformation:
    (funcall #'foo x y)  ==>
    (the t (funcall #'foo (the integer x) (the integer y))))

  Rob