From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Declaring Lisp function types Date: Sun, 03 Mar 2024 13:13: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="20436"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier via "Emacs development discussions." To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 03 19:14:42 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 1rgqMD-00059D-QF for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Mar 2024 19:14:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rgqLP-0000pm-Sk; Sun, 03 Mar 2024 13:13:51 -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 1rgqLP-0000pc-5O for emacs-devel@gnu.org; Sun, 03 Mar 2024 13:13:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rgqLN-00031M-Is; Sun, 03 Mar 2024 13:13:50 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BA6F480B20; Sun, 3 Mar 2024 13:13:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1709489626; bh=ViPjSd59NVSzqj3O0O2HTsw5JsEdLobDRAQXVNSQj8w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=h2DkF4ong16FjV/F0OiWBR/0mGJeMzYkU//wIwS+EekHkSlCauylfX9hL9VrseLPV B4Ks3kXdPPuwwZw/fIfOWRxue4CLODlLj7T/EP8mBCzqPddWEeyFIaWl7nVqYFNhYb uiSYAhd1R2RKV2vB+adRPn1IC3KH292ESo06JytDcR2d5BqRJRfCFW3/nOUy7b/Zuy pARbpyaRi5i55sIfNn6Y6dmdlDLDDAd5mlnKA4vNcQ1YanbLNNkHHWr978KSRZagSA 9TQhmNIhokdoLKL8XZ6IK4hiWxSxYeiym+amNgoUaKTbPKL8AlvEbnBsGixDAejLbg NIa+xMErLMelg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C11B2806A3; Sun, 3 Mar 2024 13:13:46 -0500 (EST) Original-Received: from pastel (unknown [104.247.233.29]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9C8761203BC; Sun, 3 Mar 2024 13:13:46 -0500 (EST) In-Reply-To: (Andrea Corallo's message of "Sun, 03 Mar 2024 12:31:45 -0500") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:316765 Archived-At: >>>> - 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. That's the point of view of the compiler writer. We need to state it from the point of view of the user, i.e. describe the potential behavior of that wrong code we might generate. Also the description should be clear enough that a user can guess what happens if the type annotation was correct but the function gets redefined (e.g. via an advice) which does not obey the same type. >> 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? I'd put it somewhere inside the "@chapter Compilation of Lisp to Native Code" in `compile.texi`. Stefan