Re: Declaring Lisp function types

[Andrea Corallo]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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.

Agree

>> 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?

At the very moment nothing as we use the declaration only for the return
type, in the future I guess we want to have settings of the compiler to:

1- emit runtime type checks for the arguments (maybe introducing
   'native-comp-safety'?)

2- Use the arg declaration for code generation optimizations (I guess
   connected to 'native-comp-speed')

I've never wanted to enable 1 and 2 as didn't sound correct having an
ad-hoc declaration hidden somewhere in the compiler, but should be
relatively easy as all the infrastructure is in place.

>>> - 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?

We might generate wrong code.  I *think* this is the same for other kind
of function declarations we already have which are in use by the
byte-compiler.

> 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.

Yep, I don't know where these info should be placed in the manual.
Maybe there should be an area dedicated to the native compiler?

  Andrea