From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Daniel_Mart=C3=ADn?= Newsgroups: gmane.emacs.devel Subject: Re: New package emacs-parser-generator Date: Mon, 29 Nov 2021 00:46:09 +0100 Message-ID: References: <9CE08016-E517-4DD3-8A7B-B55277E28A08@cvj.se> 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="15349"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (darwin) Cc: Stefan Monnier , Eli Zaretskii , emacs-devel@gnu.org To: Christian Johansson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 29 00:47:05 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 1mrTst-0003jo-VN for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Nov 2021 00:47:04 +0100 Original-Received: from localhost ([::1]:43088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrTsr-0002Ci-Pb for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Nov 2021 18:47:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrTs9-0001XB-Hk for emacs-devel@gnu.org; Sun, 28 Nov 2021 18:46:17 -0500 Original-Received: from sonic314-20.consmr.mail.ir2.yahoo.com ([77.238.177.146]:41896) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mrTs7-0007cV-7F for emacs-devel@gnu.org; Sun, 28 Nov 2021 18:46:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.es; s=s2048; t=1638143173; bh=U1METi1MPRwINp008G+n3Edu6H6Lg+Qt/CnO22WhO9A=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=XjpMUXEaOeD7lyhMmGFXCHvf4hbtRseffAKmc6SVpmmU8J7Lmgk6xH1oYMC1NiJKFLccB7uyGTycv2DfHSScZy+1QkS8VXoaUgT0sRsIg+N8uRekAIOng5UghWPiudv2za61tPbvnleoZaTjcmjmJmNGAyefI7ZOckVq3uJXy5Ntzog9SHiBILQlqvs+qsSAlpbBM58eZc6x8MM/rBxsKRMOgTc3QCuPU9yPACM/4SESwaGb/Pdt3aibt6kZOpXK18nsiAcwNALU1arzVGBWSh5+svIpbrkrfBMRVwHg269HIumZ9e29LhjugMB2S5fon5pTuVFMBG4GAzAR6Uexvg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1638143173; bh=19Yp6rCDJ6MNcXAl10nfgEmyR8iFXXFzKTQS5812Tox=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=W8kBMwU1ML2COtuJ/pB8t2+ad/y5qvYpAlM66F4wYUIsxD+XBxEjDo27kQurwLAV9CV8rhWmLm6FW7IMoEp2bgdptXywBRhDVllaqgubDVM46VI1gSWWryI+007Kq76qw3kZHLMemqGmwSXUzKourTpwmIOQVZnAY6ySh6672fDrdUpwA/1tOpRfu4kerOWCKWpHc+ihWSU/6+CZ7XE2dMqvllW1T+5ojtZY3Q10JSF8MyX+Hi0cHDPyMYQ637cWPClgM9aaS/32xASSqoNUJhHlAHTnRpK91fvnLqJW30ai4hKuQISrTb5ulZUpA68NCRLe6DTGISk0MN8Ns23fSA== X-YMail-OSG: Qt0M9yAVM1lIXnbHvPrv56tLpaeKusRswabyW8GZqyTt_cA0SnFHNKQkz_K453M _r7A_T3aQ63iqhgC_F1Ti.1SMPAF51xamnccEGTD9aVqcRdnhctsRsmF9c2k8MXrUnGnM.4BIgPX fyTn9F5AWUmVibNlkYOWxaVjb7DzU1OoB6fwJ8Aonc85oYwISDmr7GGgBwWb_g1J8HWieR.B8wom SsGLsSC4q7h7s8jDx5sVVe4Alzb2eaTOuoTKizyGWAi5vXcApgl4TEA2m9IlzxpdMoDAA24nE5DH 8j62Zs4h6cKSxeLJ.Bc7mdr8Dfq_zegXi9hzcUhLhs17khawEPcOFyCMbHDn_CrExRDIvwnRTeo1 7u24iXHeKhW0bRUwzKQo5YVpOFazuXkkufMbDh2nOC8gSQ__jw_1ybU5kvDEetQuEfvvrl7j6qzA ufUM5rkVVaAHOHI7pOKmj_uwqBjl9dGos.CLa9WpT2VIk7FTB5KntzqFIOEsw32ovF89sz6RY_c9 JMgaKPhDw4uprbSXWWfaKZL6G7GV2o_6r2rmNWr7GL4b0NJLSOGHGXESmHx.kE_6JW1JZ8cjtJIp r1fgphkVPC3JixHQBF1__GwMZeh_KXq5ajWRNJBl7r1wEgTfxX.irItl_Sk.Yu905f8oLcmadwwF OPy.z_tpYVKDKkbGCieqe0mlRjZ7W0rnnX_vD.iqoc54ZgeLW.KqEiddtkySEW55Bj9J0Odnavc2 HVhnkDs6BdDnGvmUhzXqA0zc22rVQo2pd0tkbh8CqBoisadhTvxcg6zelNWs2QfJ2wxIxpXggRcV __0wbAkBem_Y0P_jvz6ItH4DY6k3KzdyYpNntX5DUa X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ir2.yahoo.com with HTTP; Sun, 28 Nov 2021 23:46:13 +0000 Original-Received: by kubenode511.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 39f89e0580d0eadc080465670c85fe54; Sun, 28 Nov 2021 23:46:10 +0000 (UTC) In-Reply-To: <9CE08016-E517-4DD3-8A7B-B55277E28A08@cvj.se> (Christian Johansson's message of "Sun, 28 Nov 2021 14:45:40 +0100") X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=77.238.177.146; envelope-from=mardani29@yahoo.es; helo=sonic314-20.consmr.mail.ir2.yahoo.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:280442 Archived-At: Christian Johansson writes: > Well the GLR(k) algorithm might find a nondeterminstic route route in > the grammar that a LR(k) do not find, if I want to know if a code is > syntatically correct I would test it against the same type of parser > the language uses, that is a deterministic parser > >>=20 > An intuitive structure - Tree-sitter=E2=80=99s output is a concrete syntax > tree; each node in the tree corresponds directly to a terminal or > non-terminal symbol in the grammar. So in order to produce an > easy-to-analyze tree, there should be a direct correspondence between > the symbols in your grammar and the recognizable constructs in the > language. This might seem obvious, but it is very different from the > way that context-free grammars are often written in contexts like > language specifications or Yacc/Bison parsers. > >> https://tree-sitter.github.io/tree-sitter/creating-parsers#the-grammar-d= sl > > This is a big issue because each version of a language grammar would need= to be converted into tred-sitter form > > > > But anyways I don't see the issue with pluralism in the parser > generator space, why would one exclude the other? 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. To people much more familiar with this topic, is this an oversimplification that would led to the wrong abstraction? 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.