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: Wed, 30 Aug 2023 18:03:08 +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="28084"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Mattias =?iso-8859-1?Q?Engdeg=E5rd?= To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 30 20:04:26 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 1qbPYH-00073c-QA for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Aug 2023 20:04:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbPXJ-0000kx-T3; Wed, 30 Aug 2023 14:03:25 -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 1qbPXF-0000kj-SL for emacs-devel@gnu.org; Wed, 30 Aug 2023 14:03:21 -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 1qbPXC-00031a-9c for emacs-devel@gnu.org; Wed, 30 Aug 2023 14:03:20 -0400 Original-Received: (qmail 64751 invoked by uid 3782); 30 Aug 2023 20:03:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=muc.de; i=@muc.de; q=dns/txt; s=default; t=1693418595; h=date : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from : from; bh=sFdO/CxlSR5xAqtaSsbNQCAGfRpD+vzVTrYT/fE4L7k=; b=XImmaYlbk1f/W/7YXRRkR1emW/LL6kSR4OMXClLfv76gk/MNDpSwUjZh4ddd8mGxBHol/ n2TYinodlzcnWKYZXfR2XJwbe5O8A3ihJSJXN1rWgpSVVJrDN+Dj2OWYUiz4t4hR/Iv5kmD tFQ2lZCI/PXSEw9+aCIYgV5PFHcNzTH1Hed4JSZ0P81izVrmdEFmT/zwTh4XUr9ezFW6Gi9 yLPUmEOPlbbfLZj0Q9tUFxwXgtZAv8PSQDfL3b6DjDPS3V4dTipFMTLCbK8VmhWx6uF0wqN Udn+Dz3fyRhkRKjX3inPT7tTfcS+lHU+omQ0jJ/DPv9XoESo67kf+buwSMIg== Original-Received: from acm.muc.de (pd953a1ec.dip0.t-ipconnect.de [217.83.161.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 30 Aug 2023 20:03:08 +0200 Original-Received: (qmail 15440 invoked by uid 1000); 30 Aug 2023 18:03:08 -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=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:309549 Archived-At: Hello, Stefan. On Wed, Aug 30, 2023 at 19:36:20 +0200, Stefan Kangas wrote: > Alan Mackenzie writes: > > > 1. Would it be hard to make the byte-compiler not warn in the > > > situation you describe? > > > > (That situation being where an obsolete function/variable is tested for, > > and is used or not used according to the result of the test.) It would > > not be too hard, and the scheme I'm proposing (with help from Philip K.) > > is one way of doing this. > I'm asking because we already have special casing in place for > (featurep 'xemacs) -- we just constant fold it -- so I'm wondering if > it would make sense to do the same here. See bytecomp.el:5671. I looked at that, and came to the conclusion it doesn't make sense. The mechanics there would be to evaluate (if some-condition FOO BAR) at compilation time and replace it with either FOO or BAR. The problem is some-condition can vary at run time, for example by setting an option, so it would be more trouble than it's worth. > It's not the same situation exactly though, as we will often be able > to run bytecode from Emacs N+1 on Emacs N, whereas XEmacs/Emacs > byte-code compatibility is both long gone and in all likelihood not > coming back. Indeed, not. > > It may be, but it's clumsy. We would need such an alias for _each_ > > function/variable which has been declared obsolete. In my proposed > > mechanism, by contrast, one would just need to replace an `if' form by a > > `hash-if'. > Right. I guess this has been the state of the art in Emacs Lisp so > far, though. And then `hash-if' itself won't exist in Emacs 24 > either, of course, so depending on how ambitious people are with > backwards-compatibility they'll have to lug around compatibility > boiler-plate for that too. The current size of hash-if, including doc-string, is 10 lines. Add in an extra line for (if (not fboundp 'hash-if) ....), and we come to 11 lines. I think, given the heartaches and headaches suffered by package maintainers when variables/functions become obsolete or vanish, this would not be much of a hardship. > If we do go with a new macro, I'd propose naming it `static-if' (as in > APEL) instead of `hash-if', because the latter name seems to wrongly > suggest that it has to do with hashing. I looked at APEL, and its code was near identical to what I (with help from PK) wrote. I'd have nothing against the name static-if instead. As long as this doesn't raise copyright assignment problems, assuming the authors of APEL haven't assigned copyright to the FSF. > Our legacy is also older than even the C preprocessor. :-) -- Alan Mackenzie (Nuremberg, Germany).