From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Date: Wed, 30 Aug 2023 19:36:20 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10306"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 30 19:37:33 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 1qbP8H-0002XD-4r for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Aug 2023 19:37:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbP7S-0003Mk-F1; Wed, 30 Aug 2023 13:36:42 -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 1qbP7Q-0003Mc-JA for emacs-devel@gnu.org; Wed, 30 Aug 2023 13:36:40 -0400 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qbP7O-00067Z-C7 for emacs-devel@gnu.org; Wed, 30 Aug 2023 13:36:40 -0400 Original-Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-50078eba7afso171158e87.0 for ; Wed, 30 Aug 2023 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693416996; x=1694021796; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LntR3r7V3ja5006e32tFuDjO5EkQppyYTqd0d4xKlww=; b=nW4tvYAfS2xnVd5XhqcOa0skzv4pCxC7tti28Vbd0YNtnBsB0RfNkpvNoFmHP5olpD 1uz9W25v7CY6UEI1FALkI9mFwOIgk4wOAmmKND4FONQQyqXIovEunl9TAFevCx/joMoB dqTS/V44bme9HEVy5V/0GMePVYIR5T3SuWD0XJzpoHOSsyqHkwsnFqhUeYgUJI/f0fpg 1sWdrnTKT51zjE6KAh9IyzLWBCgeUoKlmHrictZbHgWZw+41Z/HupxruwwB9nCSJSOFj caD4WcXn2WzPg0u+0vKCXAVIMRIuIOhGOAQbp+YJOFuBIiJGiPeiXUqVZc/yxCN8rpVq Ij+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693416996; x=1694021796; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LntR3r7V3ja5006e32tFuDjO5EkQppyYTqd0d4xKlww=; b=L7JyPWO55YTrL2WEOAh/WRVRnv/uuapT6W3RpFxplJIf3DtxzqlaVcbpUUKcYnl8Tq v7TUeVEOtUFj4Cdrdzo8jLO7z8j1/LzAAWHBPh0FjgbwPed+3jdogwya+Emx11ccvUUO uNcSFZifbQR7XFxEsYtA+o/Njb1QjR0HcULoINgOiY42Wn20DkQKrxqPLWWbAB3cQlqG N8BhrUs4SuoBExmd+x2XFdCYPihFFzXDel+/RrhOLX/EpMxiiTux/+FviFA8F7y9caJh IUNg5ORffoma8pzfDd3/Z4etxlzdB+x7ALhEM+qsTV1XnVnOzSmNuzyE4ESHJLNaSPGV rkGw== X-Gm-Message-State: AOJu0YwTsHBbRa/lA9IVtxH6iuDDyeZ8aCulw5OMFUPoICPWjQbVaN0r YNwwpp/oAbuk5okf5cO1L5iseZKG7h3X+5fyhQU= X-Google-Smtp-Source: AGHT+IHIpc/9kmR7I07xaJDrctiLS58IzuTnNv4jss2H6nMUX66iNtolewHT26o6piA9E9Cbw32MSCWjx31QPjwR7KY= X-Received: by 2002:a05:6512:3b82:b0:4fe:ecd:4959 with SMTP id g2-20020a0565123b8200b004fe0ecd4959mr3033570lfv.32.1693416996281; Wed, 30 Aug 2023 10:36:36 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::131; envelope-from=stefankangas@gmail.com; helo=mail-lf1-x131.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:309548 Archived-At: 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. 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. > 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. 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. Our legacy is also older than even the C preprocessor.