From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: Macros considered harmful Date: Tue, 06 Sep 2022 18:33:28 +0300 Message-ID: <87fsh4ikl3.fsf@tcd.ie> References: <7e24d0aa-9980-6204-5064-5a92963ae7bd@secure.kjonigsen.net> <83026cfc-8a85-9939-bab4-5b60d4812af9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2657"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 06 17:34:52 2022 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 1oVabD-0000VA-Uy for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 17:34:52 +0200 Original-Received: from localhost ([::1]:40726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVabC-0006LH-Mp for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 11:34:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVaa3-0005HL-FB for emacs-devel@gnu.org; Tue, 06 Sep 2022 11:33:40 -0400 Original-Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:36557) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oVaZz-0006sD-1e for emacs-devel@gnu.org; Tue, 06 Sep 2022 11:33:38 -0400 Original-Received: by mail-ej1-x62c.google.com with SMTP id lz22so3323071ejb.3 for ; Tue, 06 Sep 2022 08:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=zXhZgYPWIZ0FadB/qHEARZwePH8WdeNCSSlQSLzXIo4=; b=In8c3MIeg3bTJNCd9PeEI45ALr4XyMbohHTn4Dq3i3tNVHAQxb25NyYZwVIL3LYhK9 pbyglazr9/zKGmAB8vd6DVApxRTuYLwUxgzwFhbQCTdxG5gNcJHuEwQElBtiUozNgWaL sKI+xPqcq59FOw+Onsk2bWV704cItLOkcReClUxKPzdNI/D/7TcgwADvx5iu6+irT1Aw Wuw+qYVsny6f0WDWuS13zfonh7Oaf+oQWjn3askV7x0ZijjS2T+lYcINYy4KMHNndWhi GM4JF7ptle0VPlP+GsVdsOKJ0rCuFQeKAmN0ZjD9SrcOYnea/HQj1cMtkCHnbeiYxnXP OTnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date; bh=zXhZgYPWIZ0FadB/qHEARZwePH8WdeNCSSlQSLzXIo4=; b=CHq1B76brgGaD9D749UN5oE8SuRIjpKF6wTh9qJSot6iaaNH2fJh9gYAipBev81n5q 7/CIHSHOZ33+b6JXkqB81/B0ixuPf3lkn+a8obHH5bj37n3EkctgDSoc4XjojBb9CZeR Rj9fHJj5Y4Td2l55yeey2GBPtFyxqmYzy1rrmkWaQ4GrQQrP4w/JkO25dhT3BllXCOoz uZvp/RPtvdAO7NhIsEEnbWvIRq8lrrqgZ1kwhpQYH25RjLeyIUjQO19y+jdgPf/fMh45 l9cAxDJhmPjAdP0//zbCCwwEenbERYL/EfafVsS9vhrLlhk2dbWPTj2CrJrND2Wdr9nI /DMA== X-Gm-Message-State: ACgBeo0ZCpCRegmH1nYE0zxp5Qa9ruJkjbEg6zjBrh3eggnbr+0bDvMz qJJukfDQOx3KIP7ODKiIfRFdGQ== X-Google-Smtp-Source: AA6agR4zK4z7DrQcRpaZ8Wb1A8a89H/YutuMtxtPc0A2xMZRYbF6L6wUIHHEmVqqH31PWmBTwdLEPA== X-Received: by 2002:a17:907:9801:b0:742:1206:52b1 with SMTP id ji1-20020a170907980100b00742120652b1mr26967182ejc.61.1662478410133; Tue, 06 Sep 2022 08:33:30 -0700 (PDT) Original-Received: from localhost ([2a02:587:322f:73fa:fe8e:f4bf:c81f:9673]) by smtp.gmail.com with ESMTPSA id ku20-20020a170907789400b007306a4ecc9dsm6948990ejc.18.2022.09.06.08.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Sep 2022 08:33:29 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Tue, 06 Sep 2022 00:44:37 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=contovob@tcd.ie; helo=mail-ej1-x62c.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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:294790 Archived-At: Stefan Monnier [2022-09-06 00:44 -0400] wrote: > Cl=C3=A9ment Pit-Claudel [2022-09-05 19:53:26] wrote: >> On 8/20/22 07:14, Stefan Monnier wrote: >>> FWIW, I think specifying the highlighting rules with something akin to: >>> (defvar ') >>> is a mistake. It should go through some kind of macro, such as (maybe): >>> (defvar (tree-sitter-rules )) >>> which can thus do any preprocessing we may want, such as pre-compiling >>> queries. It also helps evolve the syntax since we can more easily warn >>> about obsolete uses, etc... >>> I've had a "rewrite font-lock.el so the rules go through a macro" in my >>> todo list for ages. >> >> We do things this way in Flycheck, but we've been bitten a few times by = the >> way this pattern interacts with `with-eval-after-load`, so I would be >> careful about adopting this pattern in tree-sitter (unless we expect it = to >> be preloaded). > > Very good point. It would introduce a strong compile-time dependency on > the tree-sitter package, which could be a serious annoyance for random > `foo-mode` packages which want to keep working in the absence of > tree-sitter. > > Hmm... > > [ I guess we'd have to make that macro lightweight and independent from > tree-sitter itself and put it into a separate package distributed via > GNU ELPA, so packages can feel free to depend on it. > Hmm... Another problem. ] > >> In fact, I think your suggestion back then was to *not* use a macro? > > Indeed, > > [ Lua eshews macros altogether for those kinds of reasons, AFAIU. ] > > Admittedly, another way around these kinds of problems is to teach the > compiler how to deal with an unknown macro. I.e. something like > (declare-macro my-foo ...) so that if the compiler see (my-foo ...) but > `my-foo` can't be macroexpanded (because the macro is not yet defined), > it doesn't incorrectly compile it into a function call, but instead > residualizes it into something like a call to `eval`. Making it > interact correctly with lexical scoping could be tricky (I guess the > simplest solution would be to residualize the whole toplevel expression > in which the macro call was found). Another downside of macros not directly addressed by this approach is that packages using them may have the outrageous desire to both support older Emacsen and build cleanly, at the same time! Recall, for example, this unresolved shortdoc thread: https://lists.gnu.org/r/emacs-devel/2021-09/msg01719.html I suppose in the general case this can be alleviated only through 'compat'-like ELPA dependencies (or by expecting each package to write its own compatibility shims, of course). --=20 Basil