From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Macros considered harmful (was: Tree-sitter integration on feature/tree-sitter (severe performance issues together with linum-mode)) Date: Tue, 06 Sep 2022 00:44:37 -0400 Message-ID: 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15464"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: =?windows-1252?Q?Cl=E9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 06 06:47:29 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 1oVQUh-0003oj-RV for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 06:47:28 +0200 Original-Received: from localhost ([::1]:38414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVQUg-00028s-Nl for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Sep 2022 00:47:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVQS4-0000xh-Vh for emacs-devel@gnu.org; Tue, 06 Sep 2022 00:44:45 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9589) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVQS2-0001qo-5O for emacs-devel@gnu.org; Tue, 06 Sep 2022 00:44:43 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 601298015E; Tue, 6 Sep 2022 00:44:40 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E3A3B8071D; Tue, 6 Sep 2022 00:44:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1662439478; bh=Mhi1L4TNmAz9K889aDZQgfAPSoBbowgwYXU508DBB2c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o7UWrdgVuLpbJ6oPC+mGZms2m85oi9f8pWmK8+iWlTNOWBOe5nHFjsyCI6ROh3pEl 0dUAGnjf5TwFv61ik9tKbM/FK/9scmuDNIXthhHgTBmV49PHTL8oh/aj88YLjcaN+b 11caSmo/OHkMjNoK3FFKoVRimupmv+WThvygjEp1gBCQS5BgH/B6whOvobXUZBkkUM nrV8VpCAXZJBD4an67WG3lTvYmbaJ7nEOTLdkWAJQbq/Lqh0rPFHnw0cjxtJLXzlhb pSWqIqQux25e5zbA3bwwCSuFganTszu3Y35wZXKjazNupwoBHUgyjVoje9H8hD+vmB jjgFB0dMYQE0A== Original-Received: from pastel (unknown [157.52.9.190]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B786E1200A5; Tue, 6 Sep 2022 00:44:38 -0400 (EDT) In-Reply-To: <83026cfc-8a85-9939-bab4-5b60d4812af9@gmail.com> (=?windows-1252?Q?=22Cl=E9ment?= Pit-Claudel"'s message of "Mon, 5 Sep 2022 19:53:26 -0700") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:294777 Archived-At: Cl=E9ment 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 t= he > 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). Stefan