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: Thu, 02 May 2024 06:12:42 -0400 Message-ID: References: <8634sdjgoj.fsf@gnu.org> <86mspaq4ro.fsf@gnu.org> <8634r0oi2h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23702"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, stefankangas@gmail.com, adam@alphapapa.net, arthur.miller@live.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 02 12:13:39 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 1s2TRb-0005vJ-0A for ged-emacs-devel@m.gmane-mx.org; Thu, 02 May 2024 12:13:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s2TR2-0007OD-PE; Thu, 02 May 2024 06:13:04 -0400 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 1s2TQx-0007Ml-VW for emacs-devel@gnu.org; Thu, 02 May 2024 06:13:00 -0400 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 1s2TQv-0003ig-LO; Thu, 02 May 2024 06:12:58 -0400 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=aYKJvrTd9tory/kvKrNa3A86Ig/2X5K/wzXEl2HJFhg=; b=rjrY2eVI0EW7PBatq44h /89NG9SvuSXYovxCAbRAcCp/9iGVBxPzvDDv+ZxM6NGk/deY55+/hBXbE54f8GQiqoLyp7j1iPcXT 1n4V/3nMGH8RIWhsQyMAvIXbsy5GnUhuRAjxPZrWWasZxqD7d01JMzjXJVux8rKayA/Fy5d+0GhRE A8IqF0+iDKf7nEv0TD8cnTYSI7wmY+xPk6wITJ+S7gUsgYSyuAaf+OhXwP2nuIr13zjNU7aBKvpTF 9j8Ooh233eRWf1z1iL5VXHsWvUJIhDQuhmAj3n6+9JlF2iNxe+Rqk7aIr0lPum26ld9qFoCPfjAOE hBHYw9DKNTZP+g==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s2TQh-0007Dt-0q; Thu, 02 May 2024 06:12:45 -0400 In-Reply-To: <8634r0oi2h.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 May 2024 09:15:34 +0300") 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:318557 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: Eli Zaretskii , emacs-devel@gnu.org, >> stefankangas@gmail.com, adam@alphapapa.net, arthur.miller@live.com >> Date: Wed, 01 May 2024 16:57:58 -0400 >> >> Stefan Monnier writes: >> >> > Thanks Eli for reminding me: as mentioned earlier, I think we should >> > clarify what are the possible consequences if a type does not faithfully >> > reflect the behavior of the function. Examples of questions that one >> > should be able to answer based on the doc: >> > >> > - Can an incorrect type affect Emacs' behavior (other than performance)? >> > - And if so, can it cause a crash? >> > - What if the type is/was right but an advice does >> > not obey the original type of the advised function? >> > >> > The doc doesn't need to answer those questions directly, but it should >> > describe the possible effects of type annotations in enough details that >> > we can answer those questions. >> >> Thanks, I think it should be more clear now. I don't think we want to >> be over specific there as what the implementation does when the >> 'promise' of the declaration is not respected might change in the >> future. > > The text you added says an incorrect type produces undefined behavior. > Is that true for all alternatives of calling the function: > interpreted, byte-compiled, and native-compiled, or only with some of > these? AFAIK only native-compiled ATM. Do you think we should specify that? > "Undefined behavior" sounds scary, and I wonder whether it is really > accurate. If the practical expressions of this UB are only some > specific ones, perhaps we should mention them? For example, UB > generally means your entire system could be brought down, but I very > much doubt that this could happen due to incorrect type declaration, > could it? There are probably very few cases that can cause this (ATM I could think only of one) but if one pokes at that is actually not that difficult: (defun foo () (declare (type (function () cons))) 3) (defun bar () (car (foo))) Compiling this code and calling car crashes my Emacs. PS We might want to control this in the future adding a compilation parameter 'safety'. Andrea