From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Names for PEG Functions Date: Mon, 3 Oct 2011 20:21:36 -0400 Message-ID: References: <87mxdxfwvj.fsf@pobox.com> 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 1317687709 2066 80.91.229.12 (4 Oct 2011 00:21:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 4 Oct 2011 00:21:49 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Oct 04 02:21:45 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RAslS-00089F-4W for guile-devel@m.gmane.org; Tue, 04 Oct 2011 02:21:42 +0200 Original-Received: from localhost ([::1]:36220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAslR-00040v-GE for guile-devel@m.gmane.org; Mon, 03 Oct 2011 20:21:41 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAslO-000408-LF for guile-devel@gnu.org; Mon, 03 Oct 2011 20:21:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RAslN-000761-I2 for guile-devel@gnu.org; Mon, 03 Oct 2011 20:21:38 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:64150) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RAslN-00075u-ES for guile-devel@gnu.org; Mon, 03 Oct 2011 20:21:37 -0400 Original-Received: by iaen33 with SMTP id n33so7410738iae.0 for ; Mon, 03 Oct 2011 17:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=inK+K0bkr68eh80Xb1SScoNMLcbOSbhWv9qGPqdIK+M=; b=BmTEI6McCI8lI5Hor19YXXA2oAtoF3L/7VuZeeFu7czo5ibSLOA94xZzvNdHubTTFh N7n+XfmIJD6HVwwqa589sYAa3dC4CFugsFG6nMsb1Df1CZjg4IvPKY6IyBkov036m5Ci IBbQJidrkCdpc70bVRH4AK0rBywFg65kOHeME= Original-Received: by 10.42.97.8 with SMTP id l8mr881312icn.3.1317687696071; Mon, 03 Oct 2011 17:21:36 -0700 (PDT) Original-Received: by 10.42.180.1 with HTTP; Mon, 3 Oct 2011 17:21:36 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: VcT1LV3B6PZLen9tPt3FDm-aW8M X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12819 Archived-At: Hello, I hate to make more work for people, but I think the PEG module is almost ready for merging, and could probably be merged if we resolved this names issue. Any other thoughts? Noah On Thu, Sep 22, 2011 at 1:56 PM, Noah Lavine wrot= e: > Hello, > >>> define-peg-sexp - define a nonterminal from an s-expression >>> define-peg-string - define a set of nonterminals from a string >> >> To me this sounds like you are defining an sexp or a string, which >> doesn't make much sense. =A0I don't think that we need to preserve >> symmetry here, because the first binds one identifier, whereas the >> second binds a number of identifiers. =A0(Is that really necessary? =A0I= t >> would be nicer if it just bound one identifier, or something. =A0Dunno. > > Then how about define-peg-pattern for the s-expression one, and > define-peg-string-patterns for the strings? That at least includes the > difference in number of things bound, and also matches the names for > the compile-* functions. > > As for binding more than one identifier - you have to bind patterns to > variables if you want to reuse them in other patterns later on. If you > know in advance what patterns you will be matching, you don't need to > define any other names, but we don't really know that. One of the > advantages of PEG is the idea that you can reuse portions of grammars > in other grammars, so they compose nicely. > >> Also, are the different `accum' things necessary? =A0Just wondering. >> Unused bindings will probably be removed by the optimizer. > > Well, you can choose how much to accumulate at each s-expression, and > this makes that choice for the top level. You have to make some choice > at each level. The other option I can think of is to pick something as > default, and then say that if you want to change it you can indicate > that in the s-expression (via the special forms that do that). > >>> compile-peg-sexp - compile an sexp to a nonterminal (an opaque value >>> to the user, but really just a function) >> >> compile-peg-pattern perhaps ? >> >>> compile-peg-string - compile a string to a nonterminal >> >> compile-peg-string-pattern ? > > Sure. Just a note, though - this seems to make an s-expression pattern > the default, and string a special case. (That's how I think of it too, > but I realize that not everyone does :-) ). > >>> match-peg - match a peg to a string, starting at the beginning >> >> match-pattern ? >> >>> search-peg - match a peg to a string, starting at each index in turn >>> until we find a match or reach the end >> >> search-for-match ? > > How about 'search-for-pattern' instead, because everything else uses 'pat= tern'? > >>> I realize that putting 'peg' in the names isn't really necessary >>> because the user could use a module renamer, as Ludovic pointed out a >>> few days ago. I put 'peg' in the define-* syntax because I thought >>> 'define-sexp' and 'define-string' were too general as names, and then >>> I wanted the compile-* functions to be consistent with them. As for >>> the others, 'match' and 'search' seemed too general. >> >> Yeah, dunno. =A0What do you think about these names? =A0Please don't tak= e >> these suggestions too seriously. > > Your names seem good. I want the names to be decently self-consistent > and descriptive, but I don't care much beyond that. > > Noah >