all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Andrea Corallo <acorallo@gnu.org>
Cc: Stefan Monnier via "Emacs development discussions."
	<emacs-devel@gnu.org>
Subject: Re: Declaring Lisp function types
Date: Sun, 03 Mar 2024 09:52:23 -0500	[thread overview]
Message-ID: <jwv4jdne65n.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <yp1il231w23.fsf@fencepost.gnu.org> (Andrea Corallo's message of "Sun, 03 Mar 2024 04:52:52 -0500")

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




  reply	other threads:[~2024-03-03 14:52 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 16:02 Declaring Lisp function types Andrea Corallo
2024-02-23 23:35 ` Adam Porter
2024-02-24  7:10   ` Eli Zaretskii
2024-02-24  8:53     ` Tomas Hlavaty
2024-02-24  9:08       ` Adam Porter
2024-02-24  9:24         ` Andrea Corallo
2024-02-24 15:13           ` Tomas Hlavaty
2024-02-24 15:21             ` Tomas Hlavaty
2024-02-24 15:24               ` Tomas Hlavaty
2024-02-24  8:56     ` Adam Porter
2024-02-24 10:03       ` Eli Zaretskii
2024-02-25  7:35         ` Adam Porter
2024-02-24  9:21   ` Andrea Corallo
2024-02-25 17:04 ` Alan Mackenzie
2024-02-25 17:15   ` Eli Zaretskii
2024-02-25 17:16   ` [External] : " Drew Adams
2024-02-26 16:25   ` Andrea Corallo
2024-02-29  3:50   ` Richard Stallman
2024-02-29  6:10     ` Adam Porter
2024-02-29  9:02     ` Andrea Corallo
2024-02-26  3:38 ` Richard Stallman
2024-02-26 16:38   ` [External] : " Drew Adams
2024-02-26 16:54     ` Eli Zaretskii
2024-02-26 17:44       ` Andrea Corallo
2024-02-26 16:52   ` Andrea Corallo
2024-02-26 18:10     ` Tomas Hlavaty
2024-03-02 21:19 ` Stefan Monnier via Emacs development discussions.
2024-03-03  9:52   ` Andrea Corallo
2024-03-03 14:52     ` Stefan Monnier [this message]
2024-03-03 17:31       ` Andrea Corallo
2024-03-03 18:13         ` Stefan Monnier
2024-03-15 16:49 ` Andrea Corallo
2024-03-15 18:19   ` Tomas Hlavaty
2024-03-15 18:38     ` Eli Zaretskii
2024-03-16 13:39       ` Tomas Hlavaty
2024-03-16 14:06         ` Eli Zaretskii
2024-03-16 14:56           ` Tomas Hlavaty
2024-03-16 15:43             ` Emanuel Berg
2024-03-16 15:44             ` Eli Zaretskii
2024-03-16 15:54               ` Emanuel Berg
2024-03-18  8:55               ` Lele Gaifax
2024-03-16  0:01   ` Adam Porter
2024-03-18  9:25     ` Andrea Corallo
2024-03-26 10:13   ` Andrea Corallo
2024-03-26 10:28     ` Christopher Dimech
2024-03-26 12:55     ` Eli Zaretskii
2024-03-26 16:46       ` Andrea Corallo
2024-04-29 17:48         ` Andrea Corallo
2024-04-29 17:55           ` Stefan Monnier
2024-04-29 18:42             ` Andrea Corallo
2024-04-30 14:55           ` Eli Zaretskii
2024-04-30 18:29             ` Stefan Monnier
2024-05-01 20:57               ` Andrea Corallo
2024-05-01 21:06                 ` Stefan Monnier
2024-05-02  6:16                   ` Eli Zaretskii
2024-05-02 10:16                   ` Andrea Corallo
2024-05-02  6:15                 ` Eli Zaretskii
2024-05-02 10:12                   ` Andrea Corallo
2024-05-02 11:15                     ` Eli Zaretskii
2024-05-02 13:20                     ` Stefan Monnier
2024-05-01 20:54             ` Andrea Corallo
2024-05-02 10:22               ` Eli Zaretskii
2024-05-02 15:18                 ` Andrea Corallo
2024-05-02 16:32                   ` Eli Zaretskii
2024-03-26 13:05     ` Mattias Engdegård
2024-03-26 13:44     ` Stefan Monnier
2024-03-26 14:28     ` Joost Kremers
2024-03-26 14:37       ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2024-03-16  7:46 Arthur Miller
2024-03-16 15:46 ` Emanuel Berg
2024-03-18  9:02 ` Andrea Corallo
2024-03-18  9:58   ` Arthur Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv4jdne65n.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=acorallo@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.