[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: FUNCTION-DECLARATION (version 1)
- To: vanroggen%aitg.DEC@DECWRL.DEC.COM
- Subject: Re: Issue: FUNCTION-DECLARATION (version 1)
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 22 Sep 88 10:34:17 CDT
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of Wed, 21 Sep 88 10:34:34 PDT from vanroggen%aitg.DEC@DECWRL.DEC.COM
- Sender: GRAY@Kelvin.csc.ti.com
> 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.
Well, that depends on how you read it. I always assumed that it was just
an oversight that page 158 doesn't mention that FUNCTION is an exception
to the list in table 4-1 since the next page gives it a different meaning.
Are there any implementations that actually try to support it both ways?
Actually, now that I think about it, both forms could be supported since
there isn't really any ambiguity -- in one case the third element of the
declaration specifier must be a list and in the other it must be a non-nil
symbol if present.
> Proposal (FUNCTION-DECLARATION: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).
Maybe this would have been cleaner, but I don't see sufficient
justification for making an incompatible change now.
> Current Practice:
> VAX LISP treats FUNCTION declarations as describing only function bindings.
I'm not quite sure which you mean; do you mean it only supports the
(FUNCTION name argtypes valtypes) form? The Explorer only supports this
> 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,
That last sentence is not true, since CLtL clearly says that it is allowed
and defines what it means, so no valid implementation can disallow it.