From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christian Johansson Newsgroups: gmane.emacs.devel Subject: Re: New package emacs-parser-generator Date: Mon, 29 Nov 2021 14:09:01 +0100 Message-ID: References: <838rx7w3cv.fsf@gnu.org> Mime-Version: 1.0 (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="12550"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, =?utf-8?Q?Daniel_Mart=C3=ADn?= To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 14:10:30 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 1mrgQP-00033g-Br for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 14:10:29 +0100 Original-Received: from localhost ([::1]:46670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrgQN-0001xA-GM for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 08:10:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37878) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrgP8-00018I-7m for emacs-devel@gnu.org; Mon, 29 Nov 2021 08:09:10 -0500 Original-Received: from mailrelay4-3.pub.mailoutpod1-cph3.one.com ([46.30.212.13]:36641) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrgP5-00044D-M2 for emacs-devel@gnu.org; Mon, 29 Nov 2021 08:09:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cvj.se; s=20191106; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version:from: content-transfer-encoding:content-type:from; bh=ujKNO7cbkvR+NNxYUkaSKcJW+OSoSMkgeiC3pOdtEZc=; b=nsC+KKIL5lX4o7if+95fG6YvGMrNSKSeu73NUL7JCloIoPXNXMW1vCwO6IrcBkNk5SNIk2iPEAlp2 hLxOiLaXj3INcJMdbkIdxh919k8ktWyx4H1g5B36W6HxtZNnVqR9hOhFj/NOMAbbEF/SVcpSLcxemn m/6wVW4Ef+oAkm6PiGJvZDI9IkNcaxrnc6QK10DElbrVFlKeUpj4ct1tJu4PVos116u1T64qpox9EM EjSJMprDj7Zi4uUhsaljCWdjGUyoTZHGDo8oojqVoUnXw55VtDCTamL0x+txLgVOlEKqQqESOIkRo3 SDI8XuYhCLzyQHR6+ARVjRvhOW8izZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cvj.se; s=rsa1; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version:from: content-transfer-encoding:content-type:from; bh=ujKNO7cbkvR+NNxYUkaSKcJW+OSoSMkgeiC3pOdtEZc=; b=Ydiin0SE+NAIC3I3DinDwbvZ8FHTf2rP0e47rlo4QhhXSMIAPoTkFxO4uGsiC0CGq9o01HgxyiLl6 psfcgTfRinYLsTlCoVMRA3ssQ/RHh2AsdrvtzDQ0kiLTEwp2x04JeGjijUZJI3abszbJLfnuPh9sKM 2mSWmuC6Dbl8yORfnQuPzfoXEd2bWqJhL1XL609xPQ+415pEQ977VubUt6O8/U70ryV8/y2v7XlXEu x9gTOSHjlwdVBdmhxAQzaI+jQI1dm73I0Nz8MEAV96cEcR0I2YndhSgVK6fhVW0fId0bxWDZlqR0UO O68uxj0qZkDRqrgDX5WsN+YGqYjDFow== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=cvj.se; s=ed1; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version:from: content-transfer-encoding:content-type:from; bh=ujKNO7cbkvR+NNxYUkaSKcJW+OSoSMkgeiC3pOdtEZc=; b=saGXRAsTcdPitS3jfYRYH5CqfyC2jzjhVuwVXlMEeNUWudiTpbWP+nSMFAfZuKByTf8UGxJTZTPVL wT2HKlyDQ== X-HalOne-Cookie: a90ba35846d7a863e89426164fe308a504a8dbae X-HalOne-ID: 855c2e26-5115-11ec-ae05-d0431ea8bb10 Original-Received: from smtpclient.apple (c188-150-212-230.bredband.tele2.se [188.150.212.230]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 855c2e26-5115-11ec-ae05-d0431ea8bb10; Mon, 29 Nov 2021 13:09:02 +0000 (UTC) In-Reply-To: <838rx7w3cv.fsf@gnu.org> X-Mailer: iPhone Mail (19A404) Received-SPF: none client-ip=46.30.212.13; envelope-from=christian@cvj.se; helo=mailrelay4-3.pub.mailoutpod1-cph3.one.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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=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" Xref: news.gmane.io gmane.emacs.devel:280467 Archived-At: Hi again My main intention that I forgot to include in the original email was to requ= est to include my parser-generator library in GNU ELPA. Stefan requested tha= t to solve the dependency-problem with generating the parser for phps-mode. My library is only elisp and I think treesitter is C-based so treesitter is p= robably faster overall even though a LR(k) should be faster than a GLR(k) pa= rser in theory. Especially the lex-analyzer part is slow in my library, also= generating a parser for a complex language is ridiculously slow. Parsing i= s very fast though Regards Christian > 29 nov. 2021 kl. 13:30 skrev Eli Zaretskii : >=20 > =EF=BB=BF >>=20 >> From: Daniel Mart=C3=ADn >> Cc: Stefan Monnier , Eli Zaretskii >> , emacs-devel@gnu.org >> Date: Mon, 29 Nov 2021 00:46:09 +0100 >>=20 >> 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: >>=20 >> - 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. >=20 > 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. >=20 >> 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. >=20 > 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.