From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Lucy Newsgroups: gmane.lisp.guile.devel Subject: Re: PEG Patches Date: Mon, 28 Mar 2011 17:17:09 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1301350678 1654 80.91.229.12 (28 Mar 2011 22:17:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2011 22:17:58 +0000 (UTC) Cc: Andy Wingo , guile-devel To: Noah Lavine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 29 00:17:52 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Kky-0003oB-9l for guile-devel@m.gmane.org; Tue, 29 Mar 2011 00:17:52 +0200 Original-Received: from localhost ([127.0.0.1]:57164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4Kkx-00043F-LX for guile-devel@m.gmane.org; Mon, 28 Mar 2011 18:17:51 -0400 Original-Received: from [140.186.70.92] (port=48984 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4Kkf-0003ng-Nm for guile-devel@gnu.org; Mon, 28 Mar 2011 18:17:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4Kkd-0001CR-Js for guile-devel@gnu.org; Mon, 28 Mar 2011 18:17:33 -0400 Original-Received: from mail-wy0-f169.google.com ([74.125.82.169]:34917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4Kkd-0001Bt-9H for guile-devel@gnu.org; Mon, 28 Mar 2011 18:17:31 -0400 Original-Received: by wyf19 with SMTP id 19so3859403wyf.0 for ; Mon, 28 Mar 2011 15:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=u1lAeeHBxgsWOSnwm/0bSoE6uvYDy84jONAxyu14MOg=; b=Wwxbo8a7VXVb56kQHTountFQW8CcJgVzCLJDkJ4UjEEbcZ0vUyvfA2i9FLvfhdv3Sq BCVujvY9fw481ySnAJA7aUBb55oZXGkE1yCDWnBzA4XuMxhZaubrWEniH3FYWTQnONtc oy0fRhoKXAeM6HrczTUQEi7FShjr7ZPfkrN6U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=k469vEOB2SMeavyabFZK4s8+SQohPv1s+YqJLf6OSIMoA6ysbJ31GK77dSz5GvCsWt GFkRdxRlYi+t3FJ9CAokJSLBmqccMyfBf3NqFrNE/MZ3yxoGQqJwmZ5P/cRduLCcqGTL jTDuDDRHO/tff47K8jPyHQlG0dg7tArTOqJO0= Original-Received: by 10.227.197.83 with SMTP id ej19mr4341325wbb.105.1301350649209; Mon, 28 Mar 2011 15:17:29 -0700 (PDT) Original-Received: by 10.227.144.205 with HTTP; Mon, 28 Mar 2011 15:17:09 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 39SkG3ibWSMsXECF0IqA9gsky3A X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12034 Archived-At: A variant on the second option would be first defining peg-string-compile to just throw an error, then redefining it later to actually compile the string. That seems a little less hackish, at least to me. A fifth option would be to make peg-sexp-compile take an optional argument FUN-RECUR that it will call instead of recursing into itself (so in your example FUN-RECUR would be peg-extended-compile). This involves more rewriting than the other options to pass the optional argument around, but it's pretty clean and would allow users to write other parsing layers on top of peg-sexp-compile should they wish (achieving similar results to the fourth option). On Mon, Mar 28, 2011 at 3:44 PM, Noah Lavine wrot= e: > Hi, > >> I think the solution is to confront the circularity directly. =A0It exis= ts >> because the PEG s-exp grammar also deals with the string grammar, which >> needs an already-build PEG parser. >> >> Let's break it instead into layers without cycles: removing the string >> grammar from the s-exp code generator. =A0If we want a layer with both, = we >> build it on top of the two lower layers. >> >> What do you think? > > I've been working on that. The attached two patches break the > circularity. The code still isn't organized brilliantly, but after > applying these I think we would only want pretty minor cleanups before > merging PEG into the main branch. > > However, there's an interesting issue which I am not sure how to > confront. Here it is: > > Currently, peg-sexp-compile is defined as a big case statement: > > (define (peg-sexp-compile pattern accum) > =A0(syntax-case pattern (....) > =A0 =A0)) > > What these patches do is take out the case for embedded PEG strings, > so the case statement has one fewer case. Then they add a new function > peg-extended-compile, defined by > > (define (peg-extended-compile pattern accum) > =A0(syntax-case pattern (peg) > =A0 =A0((peg str) > =A0 =A0 (string? (syntax->datum #'str)) > =A0 =A0 (peg-string-compile #'str (if (eq? accum 'all) 'body accum))) > =A0 =A0(else (peg-sexp-compile pattern accum)))) > > peg-string-compile takes a string, parses it, and then calls > peg-sexp-compile on the result, so this is noncircular. > > Unfortunately, this sacrifices a feature. The trouble is that the > cases in peg-sexp-compile call peg-sexp-compile on parts of > themselves, because PEG expressions are recursive. Those inner PEG > expressions can never contain embedded string PEGs with this > definition, because those calls never go through peg-extended-compile. > > I see a few options: > =A0- say that string PEGs can only occur at the top level of a PEG > expression. The peg module has never been released, so no one uses > this feature now anyway. > =A0- instead of defining a new function peg-extended-compile, redefine > peg-sexp-compile via set! once we have string pegs. > =A0- write peg-extended-compile as its own big case statement, basically > duplicating peg-sexp-compile. > =A0- adopt some interface that allows people to extend the cases in > peg-sexp-compile. We would start with just s-expression PEGs, then use > this interface to add string PEGs later in the load sequence. > > The second and third options seem hackish to me. The third option is > especially bad because I think some of the calls to peg-sexp-compile > are in helper functions that peg-sexp-compile calls, so we might have > to duplicate most of codegen.scm to make this work. > > The fourth option seems elegant, but I'm not sure what a good > interface for that is. Is there anything in Guile now that can > idiomatically be used for an extensible list of cases? It seems almost > like something GOOPS would do, but not quite. I am also a bit > concerned about the fourth option because it could become an interface > that is only ever used once, and might just add unnecessary > complexity. > > I think the first option is the best one for now, because it doesn't > require much work and it would allow a smooth transition if we ever > enable non-top-level PEG strings in the future. What do other people > think? > > Noah >