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, 07 Nov 2022 11:46:36 -0800 Message-ID: <87tu3asg2r.fsf@ericabrahamsen.net> References: <875yvtbbn3.fsf@ericabrahamsen.net> <877d07a16u.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33602"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Stefan Monnier To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 07 20:47:42 2022 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 1os85t-0008YH-Nz for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Nov 2022 20:47:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1os857-0006jp-Ak; Mon, 07 Nov 2022 14:46:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1os856-0006jf-5G for emacs-devel@gnu.org; Mon, 07 Nov 2022 14:46:52 -0500 Original-Received: from mail.ericabrahamsen.net ([52.70.2.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1os852-00066w-UN for emacs-devel@gnu.org; Mon, 07 Nov 2022 14:46:51 -0500 Original-Received: from localhost (c-71-197-232-41.hsd1.wa.comcast.net [71.197.232.41]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id C035CFA07E; Mon, 7 Nov 2022 19:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1667850398; bh=pMPCLy6q6t0831S9rbRd34nCcehVE1t+vJIWJYfvTXA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WZKwY3otprWC2wwAReFzsPwjau69HOqIele+aOVVa1jFSONUN6pvVNq499ypLYitE P9TdIoYNvT4yrXseS0UvlDfw7AE65GZWCWadU9DDzAkJVELRyD4B4l1UE23lkVZDuU ZRzl5h4bqqU1tPAqILLO64Zrp1s863U4zh6i9npo= In-Reply-To: <877d07a16u.fsf@localhost> (Ihor Radchenko's message of "Mon, 07 Nov 2022 03:33:13 +0000") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, 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.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299303 Archived-At: Ihor Radchenko writes: > Eric Abrahamsen writes: > >> Would the maintainers consider moving this into Emacs proper? I ask >> mostly because this would be very useful to have in Gnus, both to >> replace the home-made parser in gnus-search.el, and I would hope to >> parse eg IMAP server responses more fully and reliably. > > Is there any progress merging peg.el to Emacs? > I do not see any obvious blockers in the discussion, but the merge never > happened? It certainly did lose momentum. I think there were some issues regarding implementation and API, some open questions, and then whoever would have needed to take ownership of the ticket and see it through did not do so. Probably that should have been whoever opened the bug report to begin with! I believe peg.el does a few things in non-standard ways. I'm not very familiar with parsing expression grammars, and I don't feel qualified to judge just how non-standard those ways are, and whether it's a real issue. But if no one has any massive objections (or plausible fixes) then personally I'd be okay with it going in like this. I'm not a maintainer though! I will say that I tried to use PEG to resolve some gruesome text-parsing issues in EBDB very recently, and failed to make it work in the hour or two I'd allotted to the problem. The file-comment docs are pretty good, but I think they would need to be expanded in a few crucial ways, particularly to help those who don't necessarily know how PEGs work. Specifically, it is not obvious (to me) the ways in which PEGs (or maybe just peg.el) are not fully declarative. It doesn't backtrack, and I suspect it won't ever backtrack or isn't even supposed to, which means users should be made explicitly aware of the ways in which their rules can fail, and the ways in which declaration order matter. The comment for the `or' construct reads: Prioritized Choice And that's about the only hint you get. I was trying to parse a multiword name like Eric Edwin Abrahamsen into the structure (("Eric" "Edwin") "Abrahamsen") using rules like (plain-name (substring (+ [word])) (* [space])) (full-name (list (+ plain-name) plain-name) `(names -- (list (butlast names) (car (last names))))) Which always fails to match because (+ plain-name) is greedy and eats up all the words. It doesn't ever try leaving out the last word in an attempt to make the rule match. I'm happy to write the docs (should it have its own info manual section?), if we really think there are no other necessary fixes/improvements. Eric