From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "T.V Raman" Newsgroups: gmane.emacs.devel Subject: Re: Macros considered harmful Date: Tue, 06 Sep 2022 09:54:55 -0700 Message-ID: References: <7e24d0aa-9980-6204-5064-5a92963ae7bd@secure.kjonigsen.net> <83026cfc-8a85-9939-bab4-5b60d4812af9@gmail.com> <87fsh4ikl3.fsf@tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15608"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Stefan Monnier , =?gb2312?B?Q2yopm1lbnQ=?= Pit-Claudel , emacs-devel@gnu.org To: "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 06 18:58:17 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 1oVbtx-0001Sf-BS for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 18:58:17 +0200 Original-Received: from localhost ([::1]:46910 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVbry-0006MH-DJ for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 12:56:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVbrA-0005oU-7W for emacs-devel@gnu.org; Tue, 06 Sep 2022 12:55:24 -0400 Original-Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]:42513) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oVbqw-0004Mx-WF for emacs-devel@gnu.org; Tue, 06 Sep 2022 12:55:23 -0400 Original-Received: by mail-pl1-x62a.google.com with SMTP id v5so11876622plo.9 for ; Tue, 06 Sep 2022 09:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=+/LVvbvokf+2iKe5rOwJY/eTORcjBnKSJ76e74fCS10=; b=Ee6G6sMBF5PY92OEb3m+y3T5VfiSI5UGjJMccMtt4+aiFL+y72+OHUedvivANLccI+ vgsK8keicdwGQgTRlzBSbs9xPXEKfRkox+uEnHFq+xAE2iy6iw4YlJbWsJ0lDdIs7nEG RTe/InivUqZa+uNwH8v1eKg3gHfr3HszxZ+qeX/QSpSeikIU2Nw5nXrVsBcSfyeWHoEP xD4dPzgKWti9dWVWaurcMnDJlHC4AJ7OrVUCkm8wq99f6jxTPn4dcvDXMid4WPvCswBg VSBMexrWcCUPjPTTNw5gpNF1u5mu09l0DME/BBDkvfsw/887nT31tUcCN5jCOj1s/X8Q wyYg== 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=+/LVvbvokf+2iKe5rOwJY/eTORcjBnKSJ76e74fCS10=; b=Ew6iMTupdLZtopin6/y7BbifysxFTedX+lBmCx5z3fCWUuWHaFTmtb5g+DgAwQC3rO VS6UlECc3ihL8reGqYzpvIXN3Sj9BuuuuEIbhskfiNM5JmQVdDXTevoKJm+ESvppliM+ D21YFMXU3a/5YTM3SnEZlYbWjaJGmXq3bojrvCi84h6YSnfH+xXzUemn9rIz0Y82Nqt7 NoHCwHwro8WXRpoN/WdZgb/Ox+aKv0O3mIIkUkb/ZfN1SBNrhMJpPK8Ra430B74Fd5Rp sOoffYDzKp2UU/qdXk0jrPxnLo+PxTJvrwWw51Z/1Yig/A5YY59A2Lx73RQH/8tdWbDQ /Gfg== X-Gm-Message-State: ACgBeo1usm45ZhST18kW2W58lEkfbpej0iy3VpYAUQbEYGHKpnc+mEeU VF0gmL/ifhLLIhPRiL5hVlU959gI+oHjvw== X-Google-Smtp-Source: AA6agR6sMp8UxZ+sCvD9haBhIa5giMXnE0ZtzYod501xu+uQtP+uPseEfs175gfP6xbgX+egHDMwIw== X-Received: by 2002:a17:902:a5cc:b0:170:d1cf:ac83 with SMTP id t12-20020a170902a5cc00b00170d1cfac83mr53856145plq.14.1662483297292; Tue, 06 Sep 2022 09:54:57 -0700 (PDT) Original-Received: from raman9 (c-24-4-174-65.hsd1.ca.comcast.net. [24.4.174.65]) by smtp.gmail.com with ESMTPSA id s4-20020a63ff44000000b0042e5fe44aa7sm8717571pgk.4.2022.09.06.09.54.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Sep 2022 09:54:56 -0700 (PDT) In-Reply-To: <87fsh4ikl3.fsf@tcd.ie> (Basil L. Contovounesios's message of "Tue, 06 Sep 2022 18:33:28 +0300") Received-SPF: pass client-ip=2607:f8b0:4864:20::62a; envelope-from=raman@google.com; helo=mail-pl1-x62a.google.com X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 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:294794 Archived-At: "Basil L. Contovounesios" writes: Note that all this gets significantly more complex in the world of native-comp as long as the .eln files are generated from the .el, rather than the .elc files. > Stefan Monnier [2022-09-06 00:44 -0400] wrote: > >> Cl=A8=A6ment 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 Thanks, --Raman(I Search, I Find, I Misplace, I Research) =817=A94 Id: kg:/m/0285kf1 =950=DC8