[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FUNCTION-DECLARATION (version 1)
- To: firstname.lastname@example.org
- Subject: Issue: FUNCTION-DECLARATION (version 1)
- From: vanroggen%aitg.DEC@decwrl.dec.com
- Date: Wed, 21 Sep 88 10:34:34 PDT
References: CLtL pp 43 (Table 4-1), 158-159
Edit history: #1, 21 Sept 1988, Walter van Roggen
CLtL permits 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 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).
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.
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 wasn't clearly possible without using the TYPE declaration.
VAX LISP treats FUNCTION declarations as describing only function bindings.
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. Such code could not have been portable,
Cost of Non-Adoption:
People will continue to be confused by function declarations.
A simpler language.
At first I had two proposals, FUNCTION-DECLARATION:DELETE and
FUNCTION-DECLARATION:FUNCTION-BINDING. The latter would be more compatible
with (believed likely) current usage, but I decided that the former
proposal was just plain better.