From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Make peg.el a built-in library? Date: Mon, 27 Sep 2021 09:18:13 -0700 Message-ID: <8735pq0z7e.fsf@ericabrahamsen.net> References: <875yvtbbn3.fsf@ericabrahamsen.net> <87bl5k87hq.fsf@alphapapa.net> <87fsuvpod4.fsf@ericabrahamsen.net> <874ka7wqko.fsf@gmail.com> <87r1db2x7r.fsf@ericabrahamsen.net> <87fstrmbf4.fsf@gmail.com> 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="8225"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:5xzSPvQ5pCMfBP6iRV4ijZB/qi4= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 27 18:19:28 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 1mUtLk-0001w2-9Z for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Sep 2021 18:19:28 +0200 Original-Received: from localhost ([::1]:33124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUtLj-0002Al-Bv for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Sep 2021 12:19:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40150) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUtKm-0000jx-2n for emacs-devel@gnu.org; Mon, 27 Sep 2021 12:18:30 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:43220) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUtKk-0008EQ-8p for emacs-devel@gnu.org; Mon, 27 Sep 2021 12:18:27 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mUtKg-0000bq-IN for emacs-devel@gnu.org; Mon, 27 Sep 2021 18:18:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:275596 Archived-At: Augusto Stoffel writes: > On Sun, 26 Sep 2021 at 08:06, Eric Abrahamsen wrote: > >> Augusto Stoffel writes: >> >>> I think it would be really cool to have PEGs built into Emacs. Things >>> like json.el could be simplified by at least (log10 2) orders of >>> magnitude with PEGs. Whatever the use case of `rx' is, PEGs are >>> probably the "real" solution. >>> >>> But I suspect this would only take traction with a fast and robust C >>> implementation like Lua's LPEG (see below for a reason). >> >> I wonder if it would make sense to adopt this elisp library for now, see >> if people use it (or want to use it but complain about speed), and >> consider translating to C if they do? > > Yes, that sounds reasonable. But the efficiency problem isn't even just > about speed, it's also about which patterns you can run at all without > exhausting the call stack. Without the “tail call optimization” that I > mentioned in the previous message, I think much of the appeal of PEGs is > gone... For someone hoping to use PEG to simplify parsing of very regular (though possibly complex) text (me), it's still pretty appealing. >> >> The elisp version has generic methods for `peg-normalize' (and >> `peg--macroexpand', though I guess that's private) which would allow >> library authors to write new peg expressions. We'd lose that with C, >> though I suppose speed vs extensibility is always the tradeoff with >> C vs Elisp. > > I'm not sure I understand this comment, and I confess I didn't look > closely at peg.el. But there's a difference between _defining_ a > pattern and _executing_ it. If the basic PEG vocabulary (sequence, > ordered choice, repetition, grammars, etc.) is implemented in C, you can > define all sorts of combinators, such as > > (define-peg-rule search (patt) > (or patt (and (any) (search patt)))) > > [or whatever the syntax is for grammars/recursive definitions], and > executing the patterns doesn't involve any Lisp calls. Yes, that's all I meant. So long as rules can still be defined in Lisp, this isn't an issue. >> In a previous message I complained a little bit about the entry-points >> to PEG as it stands now -- they're all macros. Maybe if we were thinking >> in terms of a future C translation, we could narrow the API down a >> little and lock it down, and discourage authors from using anything that >> wouldn't be made available by the future version. > > I can't say anything useful here without studying peg.el a bit, but I > think it would be ideal if PEGs are just values (which, in particular, > you can manipulate without naming) and there are functions that allow > making new PEGs out of old ones. > > And once again, Lua's LPEG is a fantastic library. It might be worth > taking a look at how it works. I don't really know anything about PEGs or the theory behind them, and was just hoping to be the squeaky wheel in this case. It would be great to improve peg.el, but I still think it would be nice to get it into Emacs first.