From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Declaring Lisp function types Date: Sun, 03 Mar 2024 12:31:45 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14103"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier via "Emacs development discussions." To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 03 18:32:24 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rgphH-0003Rm-Q6 for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Mar 2024 18:32:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgpgj-0005MX-RY; Sun, 03 Mar 2024 12:31:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgpgh-0005Kw-OS for emacs-devel@gnu.org; Sun, 03 Mar 2024 12:31:47 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgpgh-000288-EL; Sun, 03 Mar 2024 12:31:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=qZlWOoGzgo5AWrEq+kbacpUiCM8Ubzw9HiB0oyS3sEw=; b=DzojhnSO2A08rP4UkQUY NpR6S+GX6f0OpUAvyi2b09SZXYYcm4izaVI6cj25L4YzhQ8LF6H3x0/qHeoCc0ZB4+wosDQQxEwQM ciDCd6pBYO0Uz/1/DC3wY5TAsUK/mAHnmggjwZk6uO4eghW7G2iSSEDguBQYLGbUO2Z+bwTxg/q27 Zdn7quk9rpz9trbthmx4Vv+H+jeNZ+5n9MDEvvoSVuhgS/9yNibzZOXthXfeXw+5FHAyYWeWf6Idb Y+LMi/oZJKtrRa9wLGfDJE8ARBmCKV04P9C28OejCQ3XBLjIfbnZxTRhKe8zoyUNgrrmClpx7SKDk 54yuKZcU1C6yPQ==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1rgpgf-0000Xg-Kv; Sun, 03 Mar 2024 12:31:47 -0500 In-Reply-To: (Stefan Monnier's message of "Sun, 03 Mar 2024 09:52:23 -0500") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316763 Archived-At: Stefan Monnier 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 >>> )? 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