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: Introducing 'safety' compilation parameter Date: Tue, 07 May 2024 12:54:58 -0400 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="36250"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, mattias.engdegard@gmail.com, stefankangas@gmail.com To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 07 18:55:44 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 1s4O6S-0009BS-4g for ged-emacs-devel@m.gmane-mx.org; Tue, 07 May 2024 18:55:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4O5t-0004ov-O7; Tue, 07 May 2024 12:55:09 -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 1s4O5p-0004lu-EO for emacs-devel@gnu.org; Tue, 07 May 2024 12:55:05 -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 1s4O5n-0008IU-8J; Tue, 07 May 2024 12:55:04 -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=EV6DJDhVWaDbasd27Q0sa+EfGrMwrHCdxigBlm8O+3M=; b=CRyOcz0brDS0LkjMopJs pVdiYzl4SJlVgYbsDduUGvC5nyUFxP5/Bc94oSfxWoexlKEVEFEkyhFOOfnTjFO9+qDobyTN7aZAk tmXcrAQxOMQoGvlEBv6frIwG1pd8TGD09Rq2k3No5iqOdDDq1Rc64ZTZ/oqe3Aq572OsDv1YyGK6D MyMsOMCKDRbut5mJLxzbs3Gz9hRWJxMFj7xYfc2SXWkRARNySUNpkE5CJmEu2ntN6/YUxSbN7EZnw 7Ne3nw3/UgX5mrbCrT6PXKBs1IWq2pC2uzV042LRuJuT+3ySbNAu/nchtTbcw34JI5mvTmMCmgOPo 5vjQXcXAZ2YsiA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s4O5i-0003Tw-PZ; Tue, 07 May 2024 12:55:00 -0400 In-Reply-To: (Alan Mackenzie's message of "Tue, 7 May 2024 12:01:33 +0000") 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:318960 Archived-At: Alan Mackenzie writes: > Hello, Andrea. > > On Tue, May 07, 2024 at 06:37:50 -0400, Andrea Corallo wrote: >> Hello, > >> I've put in scratch/comp-safety a branch which introduces 'safety' as >> compilation parameter. > > I'm against this; see below. > >> 'safety' can be used similarly to 'native-comp-speed' both as a global >> variable to influence compilation both as a function declaration. > >> 'safety' justification of existence is ATM being able to control the >> undefined behaviour being created when function type declaration added >> by the user is not correct. > > How is this undefined behaviour? Lisp is a dynamically typed language. > If a function type declaration is added, this can only be advisory. If > it is incorrect, then by the specification of (Emacs) Lisp, the code > generated must still correctly handle its arguments and run. > >> ATM we can have two values: > >> 1 Emitted code is generated in a safe matter even if function types are >> miss-declared. > > I'm in favour of this remaining. > >> 0 Emitted code can misbehave or crash Emacs if function declarations are >> not correct and the function is native compiled (@pxref{Native >> Compilation}). > > I'm in favour of this not being merged. Crashing Emacs for valid (or > even invalid) Lisp should not be an option. > >> 1 is ATM the default. > > I see this change as one more boil-the-frog-slowly step towards turning > Emacs Lisp into a statically typed language. If this change gets merged > into master, how long will it be until these function declarations > become first common, then usual, then all but universal? It that were > to happen, it would be, in my opinion, a net loss to Emacs. Hi Alan, I'm sorry I was not clear presenting this patch. The scope of this is not to introduce UB but actually to *remove* it. Anyway your concern of having in few years code full of type declaration declaration is IMO just not realistic. Common Lisp has function type declarations since forever and type declared functions are very rare in CL codebases. This is a tool that can be useful for specific usages and not for the general case. Thanks Andrea