Re: Declaring Lisp function types

[Stefan Monnier]

>> so I see no semantic issue with using `ftype` or `type` here, unless
>> there are functions whose type could take another form than (function
>> <args> <rettype>)?  Are you thinking of types like
>> (or (function (int) int) (function (float) float))?
>
> That's a good example why it would be good to be able to accept the type
> specifier as a declaration with no tricks.

Then I'd go with

   (declare (type (function ..)))

This may be a bit more verbose, but it's simple and clear.  And to the
extent that people are worried that it could become pervasive and even
mandatory, I think verbose is good.

> On the specific case I'm not sure we want to support this in the inner
> machinery (at least for now).

+1

>> More important I think is to document what such annotations mean and
>> what they should look like (currently, this is not super important,
>> because the annotations live together with the code that uses them, but
>> if we move them outside of `comp.el`, the "contract" needs to be made
>> more explicit).
>> - How they interact with `&optional` and `&rest` (or even `&key` for
>>   `c-defun`).
> ATM we already support in type specifiers `&optional` and `&rest`:

I know, but it needs to be documented.

> Not sure we want to handle &key as well as it looks to me not very
> native to the elisp machinery.  OTOH cl-defun just expands to the
> native elisp call convention.

FWIW, I agree.

>> - What will/could happen if one of the arguments does not have the
>>   specified type?
> I think if ones does a declaration has to declare the type of all
> arguments (rest should be optional).

I mean, what happens (both at compile-time and at run-time) when
`my-fun` says (function (number) number) but we call it with a string?

>> - What will/could happen if the result does not have the
>>   specified type?
> I think we want to complete it with the inferred return type if we have
> it or t otherwise.

Same here: I meant what happens when `my-fun` actually returns nil
even though its own type declaration claims it returns a number?

Maybe we should also give a hint about the potential benefits (how it
influences the generated code), so coders can have a better idea about
when a type annotation is worthwhile and when it's not.


        Stefan