From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: Make peg.el a built-in library? Date: Thu, 30 Sep 2021 15:34:25 -0500 Message-ID: <878rzdreem.fsf@alphapapa.net> References: <875yvtbbn3.fsf@ericabrahamsen.net> <83wno8u3uz.fsf@gnu.org> <87v93s9q4n.fsf@ericabrahamsen.net> <875yvafjr9.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="10287"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 30 22:36:07 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 1mW2ml-0002Mn-Ep for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Sep 2021 22:36:07 +0200 Original-Received: from localhost ([::1]:33150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mW2mi-0006md-72 for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Sep 2021 16:36:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mW2lW-0005ob-EI for emacs-devel@gnu.org; Thu, 30 Sep 2021 16:34:50 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:49818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mW2lU-0005in-A7 for emacs-devel@gnu.org; Thu, 30 Sep 2021 16:34:49 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mW2lJ-00009z-7C for emacs-devel@gnu.org; Thu, 30 Sep 2021 22:34:37 +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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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:275927 Archived-At: Stefan Monnier writes: >> The peg-allow-symbols patch is more tentative. The issue is that _all_ >> of the entry-points to peg code are macros, meaning you can't build your >> grammar up in a variable, and then pass that variable to any of >> `peg-run', `peg-parse', `with-peg-rules', etc. Nobody will evaluate the >> variable; you have to literally write the rules inside the >> `with-peg-rules' form. It seems like a fairly plausible use-case to >> store the rules in a variable or an option, even if you're not doing >> run-time manipulation of them. The only solution, as Adam found with >> org-ql, is to `eval' one of the macros. >> >> This doesn't seem necessary! The patch has `with-peg-rules' check if the >> rules are a symbol, and take the `symbol-value' if so. But I wonder if >> it wouldn't be nicer to break some of the code out: `peg-normalize' >> seems to be the entry-point for "compile this grammar", and that could >> be modified to work the way that some languages provide for pre-compiled >> regexps: a way to let the developer build and compile the grammar at >> load-time or launch-time, then feed the stored compiled version to >> parsing routines. > > `peg` is the macro that's supposed to be this compilation step: you pass > it a PEX and you receive a value in return. It's a bit like `lambda`. > > You can then use this value (a "peg matcher") to parse something by > passing it to `peg-run`. > > So you can do > > (let ((parser (peg PEX))) > ... > (peg-run parser ...) > ...) > > What might still be missing, tho is a way to invoke this `parser` from > within a PEX. So we might want to add a new PEX form that would be akin > to `funcall`. We could name it `call`: > > (let* ((parser (peg PEX)) > ... > (with-peg-rules > ((foo ...) > (bar ... (call parser) ...) > (baz ...)) > ...)) > > so (peg-parse (call FORM)) would end up equivalent to (peg-run FORM ...). > WDYT? In org-ql, the PEX is redefined at load time and/or run time, being derived from search keywords that are defined by the package and possibly by the user. So the PEX can't be defined in advance, at compile time. So having to use `with-peg-rules' means having to use `eval'. That's why it would be nice to have a `peg' function that could be called with a PEX form, to return a function that could be stored in a variable and later be called with a string argument, that would parse the string with the PEG. Sort of like Python's re.compile.