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: Sun, 28 Nov 2021 14:45:40 +0100 Message-ID: <9CE08016-E517-4DD3-8A7B-B55277E28A08@cvj.se> References: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-7F8E38E6-96C7-41CE-89D2-B9F697C6D28C Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28905"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 28 14:48:10 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 1mrKXJ-0007Ky-Rf for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Nov 2021 14:48:10 +0100 Original-Received: from localhost ([::1]:36802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrKXI-0005dq-Hd for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Nov 2021 08:48:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrKV2-0003Iu-GL for emacs-devel@gnu.org; Sun, 28 Nov 2021 08:45:48 -0500 Original-Received: from mailrelay3-3.pub.mailoutpod1-cph3.one.com ([46.30.212.12]:40572) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrKUz-0002wL-FJ for emacs-devel@gnu.org; Sun, 28 Nov 2021 08:45:48 -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=yv/+8v5SzgraOKNFCX9IE5UmjNJ9u835DwMClod5z2c=; b=O984N7XPBvR3Lf59dPX5qHP2oJ7kizBwmjE6snfbrMimgCnZuMd1wZDR/tSkUBIXlDiU2p1W5Enz3 1gmF6UH+VoF3sIk5COUr+kplpCAApWptA/urfdVLd5KkppcBtHW/SOZr3IgpUIB2YBc5R93Myhv9bb XJSJa1HwaVB1AW3JQHfV3BMOrAUPseq0jlxYxH5BgxxHAJEFLXqWlpCcm2Iq9XGMD5qKuhNeGLwalb sBMtp2tETSQdoPfZ2axzz1hDDc1duztvhO5OX1vnhaM559lZQ89bHZcqBqTbDgkv9xa08d3ceIKWrX /Gn+rq8GPEunSQtV1x2d5nX+ndzhTlQ== 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=yv/+8v5SzgraOKNFCX9IE5UmjNJ9u835DwMClod5z2c=; b=KVmM1dELQqkSjmzr8i13y38SNLqa2/DW8HKYgb/EkfelM3XyPh1InZQqxyJgT3qirfeqPbCEQz+5D txmAwmPLaA1sHr9ak5MhCHkVlmpGyCSvdpZsCkJTyquIjFTkjR2hHXE8BUc1bLs7p6y0xCjGpASeJg MuuBWMeMzKQJlMbITdplSfKwSPko7dRPiydFnj8BuCsLEfMnq5vvStlZhNhpO3jM1oJdpN0kpPywu5 Wcej4vHLRYAMGoZnyV+APzCyjHgmfilK2HIG6qCjpU6uLw1f2dUf1+uaIzT13GOVWDWLOneyUFe7iO BPB8RlAPSQdUM50S8lXuhsdjqZsbNBQ== 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=yv/+8v5SzgraOKNFCX9IE5UmjNJ9u835DwMClod5z2c=; b=NjPWh1WJXNtMjojm/uKrCVhGM/TgzG/NwEYkxkmVrsQyNRAqusi52dtYMlWIueUEw5nnlw/gE4J7w llMZtvRCA== X-HalOne-Cookie: 839c6d35e60b697a95d8bf543a3cb6b46b107a4f X-HalOne-ID: 7a050d79-5051-11ec-87a6-d0431ea8bb03 Original-Received: from smtpclient.apple (c188-150-212-230.bredband.tele2.se [188.150.212.230]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 7a050d79-5051-11ec-87a6-d0431ea8bb03; Sun, 28 Nov 2021 13:45:41 +0000 (UTC) In-Reply-To: X-Mailer: iPhone Mail (19A404) Received-SPF: none client-ip=46.30.212.12; envelope-from=christian@cvj.se; helo=mailrelay3-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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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:280412 Archived-At: --Apple-Mail-7F8E38E6-96C7-41CE-89D2-B9F697C6D28C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well the GLR(k) algorithm might find a nondeterminstic route route in the gr= ammar that a LR(k) do not find, if I want to know if a code is syntatically c= orrect I would test it against the same type of parser the language uses, th= at is a deterministic parser >=20 An intuitive structure - Tree-sitter=E2=80=99s output is a concrete syntax t= ree; each node in the tree corresponds directly to a terminal or non-termina= l symbol in the grammar. So in order to produce an easy-to-analyze tree, the= re should be a direct correspondence between the symbols in your grammar and= the recognizable constructs in the language. This might seem obvious, but i= t is very different from the way that context-free grammars are often writte= n in contexts like language specifications or Yacc/Bison parsers. > https://tree-sitter.github.io/tree-sitter/creating-parsers#the-grammar-dsl= 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 spa= ce, why would one exclude the other? Regards Christian > 28 nov. 2021 kl. 14:24 skrev Stefan Monnier : >=20 > =EF=BB=BFChristian Johansson [2021-11-28 08:22:48] wrote: >> I believe tree-sitter is not suitable for proper parsing (it does not >> support LR(1) for example) >=20 > Really? AFAIK it uses a GLR parser and hence handles LR(1) and more. >=20 >=20 > Stefan >=20 --Apple-Mail-7F8E38E6-96C7-41CE-89D2-B9F697C6D28C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Wel= l the GLR(k) algorithm might find a nondeterminstic route route in the gramm= ar that a LR(k) do not find, if I want to know if a code is syntatically cor= rect I would test it against the same type of parser the language uses, that= is a deterministic parser

= > 

  1. An intuit= ive 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 se= em obvious, but it is very different from the way that context-free grammars= are often written in contexts like language specifications=  or Yacc= /Bison p= arsers.

    > https:/= /tree-sitter.github.io/tree-sitter/creating-parsers#the-grammar-dsl

    <= p style=3D"box-sizing: border-box;">This is a big issue because each version= of a language grammar would need to be converted into tred-sitter form

    <= p style=3D"box-sizing: border-box;">

    But anyways I don't see the issue with pluralism in the parser generato= r space, why would one exclude the other?


    Regards

    Christian


28 nov. 2021 kl. 14:24 skrev Stefan Monnier <monnier@iro= .umontreal.ca>:

=EF=BB=BFChristian Johansson [2021-11-28 08:22:48] wrote:
I believe tree-sitter is not suitab= le for proper parsing (it does not
support LR(1) for example)
=
Really?  AFAIK it uses a GLR parser and hence handles LR(1) a= nd more.


  &nbs= p;    Stefan

= --Apple-Mail-7F8E38E6-96C7-41CE-89D2-B9F697C6D28C--