From: Noah Lavine <noah.b.lavine@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Names for PEG Functions
Date: Mon, 3 Oct 2011 20:21:36 -0400 [thread overview]
Message-ID: <CA+U71=N5VxG0h3u77tRd6Ld5J7+cpMOPnv6ymqnykH=pZ_uTxg@mail.gmail.com> (raw)
In-Reply-To: <CA+U71=MJoEyK=2uSs9EJLOEkY+WRaauL6+Lur1ofL=3683U6Tw@mail.gmail.com>
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 <noah.b.lavine@gmail.com> wrote:
> 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. I don't think that we need to preserve
>> symmetry here, because the first binds one identifier, whereas the
>> second binds a number of identifiers. (Is that really necessary? It
>> would be nicer if it just bound one identifier, or something. Dunno.
>
> 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? Just 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 'pattern'?
>
>>> 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. What do you think about these names? Please don't take
>> 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
>
next prev parent reply other threads:[~2011-10-04 0:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 20:13 Names for PEG Functions Noah Lavine
2011-09-21 20:45 ` Andy Wingo
2011-09-22 17:56 ` Noah Lavine
2011-10-04 0:21 ` Noah Lavine [this message]
2012-01-04 18:12 ` Andy Wingo
2012-01-19 9:53 ` Andy Wingo
2012-01-19 13:54 ` Noah Lavine
2012-01-20 3:18 ` Noah Lavine
2012-01-22 20:15 ` Noah Lavine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+U71=N5VxG0h3u77tRd6Ld5J7+cpMOPnv6ymqnykH=pZ_uTxg@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).