From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New package emacs-parser-generator Date: Mon, 29 Nov 2021 14:30:56 +0200 Message-ID: <838rx7w3cv.fsf@gnu.org> References: <9CE08016-E517-4DD3-8A7B-B55277E28A08@cvj.se> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17770"; mail-complaints-to="usenet@ciao.gmane.io" Cc: christian@cvj.se, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel =?utf-8?Q?Mart=C3=ADn?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 13:31:46 2021 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 1mrfov-0004TC-Na for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 13:31:45 +0100 Original-Received: from localhost ([::1]:38374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrfot-0000iS-NG for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 07:31:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51160) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrfny-0008D4-Lf for emacs-devel@gnu.org; Mon, 29 Nov 2021 07:30:46 -0500 Original-Received: from [2001:470:142:3::e] (port=39766 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrfnx-00056V-5n; Mon, 29 Nov 2021 07:30:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iaq2RB/u+PW89cSUC2Ys97O1TKbODnbuQl4zysQAoxo=; b=gkCScPaOuH/3EvvvG96V FDXf4wPPxXcp90QVP+lVgBfROFPWtw0Wx6KfQlazA34peFeGJZhTNFqqyJjhKJR0Hdnw+duGa4TWH 0c9YTYQ5te2roUOnz+YR2Y3kQXt3QNfbM2OG4j9KcAQ9pGRIvtPLCpSqhK+10jL0E0Dcyg2K1RSCS 23wIDdO1LQMY7pIqJqY930bhOE7fodoz+5lapfAI0Bx5RBvjjQCD/9VawY8aBZnbF+yNRgtL6ef8n Szqf35bAVmyO7vrb9fxnUZAo3y/f3oCpyosw90FOWB7uPwBAfPggHDovAZBR+FeeJHYbX76s3TFM6 Iz/2La33kEAa8Q==; Original-Received: from [87.69.77.57] (port=4742 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrfnw-00011Q-Tc; Mon, 29 Nov 2021 07:30:45 -0500 In-Reply-To: (message from Daniel =?utf-8?Q?Mart?= =?utf-8?Q?=C3=ADn?= on Mon, 29 Nov 2021 00:46:09 +0100) 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:280461 Archived-At: > From: Daniel Martín > Cc: Stefan Monnier , Eli Zaretskii > , emacs-devel@gnu.org > Date: Mon, 29 Nov 2021 00:46:09 +0100 > > I think the main question is not about this library vs. Tree-sitter. We > can have both. But IMO we should spend some time investigating if a > common API is possible and makes sense. To the untrained eye, both > libraries solve the problem of generating parsers for languages, and the > use cases seem to be more or less the same, so maybe there's an > opportunity to abstract what's common: > > - Create a parser from a grammar (the way grammars are defined differs). > - Parse a region of text and generate a syntax tree. > - Query the syntax tree. > - etc. I'm not sure this is the correct approach to the issue. We should instead to ask ourselves: "what information would Emacs want from a parser for use in features like indentation, syntax highlight, refactoring, etc.", and devise the APIs that would be convenient and would make sense for those Emacs jobs. The kind of information and data that a parser can provide should be considered in the light of those Emacs requirements, and then we have a better chance of coming up with common APIs. > One thing I saw in the in-progress Tree-sitter ELisp API is that it > feels a bit too coupled to Tree-sitter. I think in the long run it's > better for Emacs to have an abstract API similar to the package you > propose here, where Tree-sitter could be one possible alternative > implementation. That's true and agreed, but until someone comes up with at least one more parser and proposes a common API, discussing this will tend to be academic, I think.