From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Introducing 'safety' compilation parameter Date: Tue, 7 May 2024 12:01:33 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18076"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, mattias.engdegard@gmail.com, stefankangas@gmail.com To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 07 14:02:50 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 1s4JWz-0004Wn-U4 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 May 2024 14:02:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s4JWH-0005vK-Et; Tue, 07 May 2024 08:02:06 -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 1s4JW5-0005oX-Ol for emacs-devel@gnu.org; Tue, 07 May 2024 08:01:57 -0400 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s4JW4-0002Gt-4T for emacs-devel@gnu.org; Tue, 07 May 2024 08:01:53 -0400 Original-Received: (qmail 15323 invoked by uid 3782); 7 May 2024 14:01:34 +0200 Original-Received: from muc.de (pd953a086.dip0.t-ipconnect.de [217.83.160.134]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 May 2024 14:01:34 +0200 Original-Received: (qmail 6097 invoked by uid 1000); 7 May 2024 12:01:33 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable 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:318935 Archived-At: 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. Why do we need this change at all? It may generate somewhat faster (or smaller) code, but isn't native compiled Lisp already fast enough, particularly on a modern machine? > I didn't want to give safety a prefix (byte- or comp-) as I believe we > should extend safety in the future with a value to have the byte > compiler generates runtime type checks to verify the declred types. > OTOH this is creating a warning for a missing prefix, not sure what's > the best way to fix this (give it a prefix or silence the compiler if > possible). > Also I added some doc for the declaration, but didn't kwnow where in the > manual the documention for the variable should go as now it has effect > only for the native compiler. Should I document it under > "Native-Compilation Variables" for now? > Thanks > Andrea -- Alan Mackenzie (Nuremberg, Germany).