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: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Date: Mon, 4 Sep 2023 10:50:07 +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="13367"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ulm@gentoo.org, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 04 12:51:15 2023 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 1qd7Ao-0003GO-Hx for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Sep 2023 12:51:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qd7AG-0004Yr-3K; Mon, 04 Sep 2023 06:50:40 -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 1qd7A9-0004TD-IY for emacs-devel@gnu.org; Mon, 04 Sep 2023 06:50:35 -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 1qd79z-0001ez-Iu for emacs-devel@gnu.org; Mon, 04 Sep 2023 06:50:32 -0400 Original-Received: (qmail 23077 invoked by uid 3782); 4 Sep 2023 12:50:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693824609; h=date : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from : from; bh=m/FMBXEuoHJyoV5ckyyb3wfJYhxId5Ra13tTZkDJdZc=; b=Vo+KF8vqPWFy5xmOrBQMkmB5MNYjdX5qXaCpzp+ZaqOrmPYvSMD1Y0qPYmFVl7/AHQ/db wc/jcY3buOJpp4djRPQSh7rOMetUApORFe6jyVnGbtLnc0KAdxlHThEMPr70UHbbxZQZSIA X8B4467/9thpzVp+jS32u7rCkNg20rUT7Cfcir6VSQJNJ/VnWXPyMrVqbkCWl2yQ9QkpG2i SvUTx/6gf6YmKSwOXC/MebvciZtiaQzakM3PMJvQV1Er0Ejj5azkUiN0q1US2+Zpyvk8vAx sk9Rol1fISxIXfqetaxFJu92lbfFPURVEL8sOmd46SAjoljATTMPmigAvbxg== Original-Received: from acm.muc.de (pd953a278.dip0.t-ipconnect.de [217.83.162.120]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Sep 2023 12:50:08 +0200 Original-Received: (qmail 4366 invoked by uid 1000); 4 Sep 2023 10:50:07 -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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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:310064 Archived-At: Hello, Richard. On Sun, Sep 03, 2023 at 21:34:08 -0400, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > > > (defadvice .....)) > > > > However, when evaluating the containing defun/defmacro rather than byte > > > > compiling it, the irritating warning message will appear with the e-w-c > > > > strategem, but not with hash-if. ;-) > > > How about making the byte compiler recognize the construct > > > (if (< emacs-major-version NUMBER) ...) > > > and do this optimization on it? > > > I think that will DTRT when compiled and when interpreted, > > > and it won't require changes in the code of the programs that use it. > People propose to handle conditions about Emacs version numbers in > a more optimized way. I proposed a simple syntax for that. > Isn't it better? I don't think it is. > > The conditions we want to test are sometimes/frequently expressed in > > terms of the (non-)existence of variables, etc. It would be > > inconvenient for package maintainers to have to determine "critical" > > Emacs version numbers to use. > I don't follow you, Haven't we been talking about conditions on Emacs > versions all along in this discussion? I did not propose that as a > change, I carried it along. For example, in CC Mode there is a chunk of code looking like .... (when (fboundp 'electric-indent-local-mode) ; Emacs 24.4 or later. (electric-indent-local-mode (if c-electric-flag 1 0))) , and there are quite a few instances like it. Here, there is a comment about which versions are relevant, but that is somewhat unusual. Note here that we would have to test both the major and minor version numbers to do this correctly. I intend to replace that code with (static-if (fboundp 'electric-indent-local-mode) ; Emacs 24.4 or later. (electric-indent-local-mode (if c-electric-flag 1 0))) .. (hash-if has been renamed static-if.) It would be more work to replace it with (when (or (> emacs-major-version 24) (and (= emacs-major-version 24) (>= emacs-minor-version 4))) (electric-indent-local-mode (if c-electric-flag 1 0))) , and that's not even taking into account the one-time effort to put special handling into >, >=, <, <=, =, /= (?etc.) for emacs-m\(aj\|in\)or-version. I haven't looked into this in any detail, but it might be quite a lot of work. > > Why do you think a more restricted test of the version number would be > > better than a more general test? > If people would like other tests too, I have nothing against them. > The issue is how to implement whatever tests we support. If they can > be done at compiler time, isn't this the better implementation? static-if is a completely ordinary macro which is 10 lines long (including doc string), and there's a new section in the elisp manual for it. Amending the evaluator and byte compiler for special handling for emacs-m..or-version would be more than 10 lines. There are currently just 45 occurrences of emacs-major-mode in our Lisp sources, and most of these are comparisons with a decimal number. Editing each occurrence by hand to use static-if would still be less work than amending the evaluator and byte compiler for special handling. We have just over 2000 occurrences of boundp and fboundp, some of which will be used to isolate code to be evaluated only when the variable/function is bound or not bound, as in the above CC Mode snippet. > I guess I don't follow. Why do you prefer `hash-if' rather > than this simple compile-time syntax? Why change the syntax rather > than using the syntax we use now? Because of the complexity of adding suitable special handling for emacs-m..nor mode to the evaluator and byte compiler compared with the simplicity of the new macro, and the relative ease of adapting existing code. > -- > Dr Richard Stallman (https://stallman.org) > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) -- Alan Mackenzie (Nuremberg, Germany).