Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION)

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

Issue:        DECLARE-FUNCTION-AMBIGUITY

References:   CLtL pp 43 (Table 4-1), 158-159

Category:     CHANGE

Edit history: #1, 21 Sept 1988, Walter van Roggen
              #2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)


Problem description:

CLtL permits confusing and ambiguous FUNCTION declarations.  One can say
  (DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type.  Yet
one can also say
  (DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.

The former is an abbreviation for
  (DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
  (DECLARE (TYPE FUNCTION X Y Z))

The ambiguity arises in a case like
  (DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.

The most important problem, though, is that using the same declaration for two
completely different purposes can lead to confusion among people writing or
reading such code.


Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE)

The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).

The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).


Rationale:

Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings.  This is a more
uniform solution than making an exception to table 4-1.

Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.


Current Practice:

VAX LISP treats FUNCTION declarations only as abbreviations for FTYPE
declarations.

Cost to Implementors:

Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.

Cost to Users:

Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.

Cost of Non-Adoption:

People will continue to be confused by function declarations.

Benefits:

A simpler language.

Esthetics:

Discussion:

Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods (MTYPE?).

Since all cases can be disambiguated after all (the original proposal
didn't realize that one couldn't declare the type of the constant NIL to
be a FUNCTION), compatibility considerations might deem this proposal to
be unnecessary.  However, van Roggen believes that making declarations
simpler and less confusing is more important than compatibility in this case.

The proposal was renamed from FUNCTION-DECLARATION after Masinter pointed out
that this issue had already been considered and named.