From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.devel Subject: Re: Make peg.el a built-in library? Date: Sun, 26 Sep 2021 20:36:31 +0200 Message-ID: <87fstrmbf4.fsf@gmail.com> References: <875yvtbbn3.fsf@ericabrahamsen.net> <87bl5k87hq.fsf@alphapapa.net> <87fsuvpod4.fsf@ericabrahamsen.net> <874ka7wqko.fsf@gmail.com> <87r1db2x7r.fsf@ericabrahamsen.net> 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="6635"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 26 20:42:35 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 1mUZ6g-0001W9-SM for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Sep 2021 20:42:34 +0200 Original-Received: from localhost ([::1]:40256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUZ6f-0000jp-SJ for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Sep 2021 14:42:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUZ1C-0002oB-4i for emacs-devel@gnu.org; Sun, 26 Sep 2021 14:36:54 -0400 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:37627) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mUZ0x-0006yg-2W for emacs-devel@gnu.org; Sun, 26 Sep 2021 14:36:53 -0400 Original-Received: by mail-wr1-x42e.google.com with SMTP id t8so45347494wrq.4 for ; Sun, 26 Sep 2021 11:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=ktmjVdsnnmEF27kejn5rgB15zQaXpXgOIXdMRmUHdus=; b=YXz9emJXL3SbGx4JVzLWXHKWSBeoULzcp/QPNz+1JRWoAn9sY9Xf+kK26L3LBkEaPi 1UmSFaDGpiJevmIOEdolx7MlovFTMGooxs2e6PFFtaSJgsTqfjiBNy3w4MtkgVkkriOp /SGW512NJcS0CzBispTZd6ZlGbCZsCtvMq4lj9G7jpvN+uqAJc6h87aiBAGrTfwJe2+V Sbli+HC049jSabuftQs30wLxZXn44mXn03N7CI+9k1ADAZIhumvjEcqGx7vVP1kxHx7P +PubUOit1m29hsWw1fqEzZSwfyGqxdlDw/fjzU+/KKDg/baTiqj0a5JUv/DkIhwn51kO 6Jjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=ktmjVdsnnmEF27kejn5rgB15zQaXpXgOIXdMRmUHdus=; b=AY/2cA1sBGfxG3QzdnAhnqRAncr4fFEZBHm048butydKAefNWkW3e18ubuNC8fs8Ub cdFdNnj7qnJ02WlkDK1l9tnXKZ34yUk79q+VkF10EL4ZNcTBZf2orLXn3KnMxjIhuuaE DSdJD0Em1Qn0iQblnXsrAJTJHBji092MK4BB+0z3sPIGD418JKJ0wz01gJh6ERyMHMGF FOOv7fJX49jrpYk45zfvbrEFYeEhbG/FIFM/9V456wUswdg2d1fFGVoyMQWr/Aq2J8tS I0IeVAJeOEyw1atl53n2GbKvXqWPJpTD1A3l/+vxZ8OUNQPxfMTWdAiW/V0UB579qmwP YUWQ== X-Gm-Message-State: AOAM530jWWk4jv4ZKo5J41DqeGpjd2wYiP+o7kQe4Gtv60V4zTPAqSLy 08G+T7XT42ki5TBIxGqzSIJNWWjLOr8= X-Google-Smtp-Source: ABdhPJyZoeO6HXzkjpzg4PF56Nk0iQ85Mooz8Gs39jZAWZwwj9zhtnEjyPhdNp4/jwtGqh/UNnDiRA== X-Received: by 2002:a1c:f302:: with SMTP id q2mr12475832wmq.56.1632681396558; Sun, 26 Sep 2021 11:36:36 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::2f72]) by smtp.gmail.com with ESMTPSA id k26sm10290402wms.39.2021.09.26.11.36.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Sep 2021 11:36:36 -0700 (PDT) In-Reply-To: <87r1db2x7r.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 26 Sep 2021 08:06:00 -0700") Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=arstoffel@gmail.com; helo=mail-wr1-x42e.google.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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:275526 Archived-At: On Sun, 26 Sep 2021 at 08:06, Eric Abrahamsen wro= te: > 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 =E2=80=9Ctail call optimization=E2= =80=9D that I mentioned in the previous message, I think much of the appeal of PEGs is gone... > > 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. > > 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. > > Eric