From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Make peg.el a built-in library? Date: Thu, 17 Nov 2022 12:21:46 +0000 Message-ID: <87a64pbwkl.fsf@localhost> References: <875yvtbbn3.fsf@ericabrahamsen.net> <877d07a16u.fsf@localhost> <87tu3asg2r.fsf@ericabrahamsen.net> <87edud25ov.fsf@localhost> <87a6511ku0.fsf@ericabrahamsen.net> <87wn85z0zl.fsf@ericabrahamsen.net> <87leobplpv.fsf_-_@ericabrahamsen.net> <87bkp7ct7f.fsf@localhost> <875yfe7ols.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14811"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 17 13:22:18 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 1ovduL-0003fD-W0 for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Nov 2022 13:22:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovdtS-0004YS-AZ; Thu, 17 Nov 2022 07:21:22 -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 1ovdtK-0004LY-An for emacs-devel@gnu.org; Thu, 17 Nov 2022 07:21:15 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovdtH-0001Po-Vr for emacs-devel@gnu.org; Thu, 17 Nov 2022 07:21:14 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1A4C824002A for ; Thu, 17 Nov 2022 13:21:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1668687669; bh=pZMRkF0PQDWXwb86ZiPOs9Xh31ogHVY9LoBOzZpREMs=; h=From:To:Cc:Subject:Date:From; b=VetW5iXAY/c5J2sg45KuXNhoswav8FC8haa/yAPbfryKa/uA6WORG140DzTrQPsdS dTv/Voy3aXPAcEzgllqoMnT12I/cUj2b4VKqsDXouGBMESc452l0fqHe8IOFA9eNyN 5zDEY+kQ4R9mPIAMWQ5shF1iot1X06SoDO+4iRZSaVRXxK0jV4mpDH1Bez6BJWyzxl /GlpPG74ARKC+uelZoP2rg7XO/5pleH2MwxTaIVWLCvMxDPuJQhmLgGzRuTSQ2g9Wq bNjFPRxYstHBrME/2ONKKOJGuQfP9c62tosBUpyN4MNoeVFbGOsXYNyPdb1O+8IHLT zAWaDHukHSsfg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NCfCP15XQz9rxF; Thu, 17 Nov 2022 13:21:04 +0100 (CET) In-Reply-To: <875yfe7ols.fsf@ericabrahamsen.net> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de 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, RCVD_IN_DNSWL_NONE=-0.0001, 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:300042 Archived-At: Eric Abrahamsen writes: >>> +@item (* E) >>> +Zero or more of an expression, as the regexp ``*''. >>> + >>> +@item (+ E) >>> +One or more of an expression, as the regexp ``+''. >> >> It is worth highlighting the greedy part here and referring to &A and >> !A. > > I don't believe there is separate syntax for &A and !A -- those are > written (if A) and (not A). Indeed. I just felt lazy to write (if A) and (not A) and wrote &A and !A :) The comment is suggesting to add reference to the (if A)/(not A) and the "Writing PEGs" section. >> Actions are only run when the expression matches; with point moved after >> the match, right? What about &A and !A? > > That's right, actions only run if the parsing succeeds, and they run all > at once at the end. Maybe I can move all discussons of parsing success > vs failure into one place. I think that there might be confusion here because people are used to full success/full failure but not to partial success. And (if A) feels even more confusing because it does not actually move point and does not advance the parser. So, it is unclear what success means and what is the buffer/stack context when action is executed. >>> +@item (list E) >>> +Match E, collect all values produced by E (and its sub-expressions) >>> +into a list, and push that list to the stack. >>> +@end table >> >> This one is not very clear. Does it imply that E is recursively wrapped >> into substring? > > It's not very clear because I don't fully understand it! It does not > implicitly create any value-returning calls (such as `substring'). I > think what it means is that, by default, values returned by actions are > all spliced into a single flat list. If you need some of those values to > be returned in a sub-list, you can use this form. > > It's a bit tricky to use because the E in (list E) could potentially > descend many levels and branch out into any number of sub-expressions, > so you need to have a clear mental model of what values might ultimately > be coming out of E. I guess that's also true for the whole thing, > though. I also don't fully understand this, but I tried to play around with the following: (with-peg-rules ((name (substring (+ [word])) (* [blank])) (given-name name (not (eol))) (last-name (list name) (if (eol))) (full-name (list (+ given-name)) last-name)) (peg-run (peg full-name))) ;; Eric Edwin Abrahamsen ;; => (("Abrahamsen") ("Eric" "Edwin")) ;; Suggested stack states: ;; 1. nil ;; 2. Match Eric via given-name: ("Eric") ;; 3. Match Edwin via given-name: ("Edwin" "Eric") ;; 4. No more match for given-name. List operation: (("Eric" "Edwin")) ;; 5. Match Abrahamsen via last-name. ("Abrahamsen" ("Eric" "Edwin")) ;; 6. Done with last-name. List operation: (("Abrahamsen") ("Eric" "Edwin")) ;; 7. done So, one may think that the stack values coming from E in (list E) are simply reversed, wrapped into a list, and pushed back into the stack. Kind of group operation. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at