Names for PEG Functions

Names for PEG Functions

[Noah Lavine]

Hello all,

As the PEG module nears some reasonable level of completion, we should
figure out what all of the functions need to be named so everyone can
reasonably understand them.

At first I thought the names should be consistent wtih the LALR and
regexp modules, so all of the parsing modules would agree. But after
looking at those two, I realized that they aren't consistent with each
other, so it would be very difficult to make PEG match them.

At least, however, PEG can be consistent with itself. Therefore I
suggest the following names and meanings:

define-peg-sexp - define a nonterminal from an s-expression
define-peg-string - define a set of nonterminals from a string
compile-peg-sexp - compile an sexp to a nonterminal (an opaque value
to the user, but really just a function)
compile-peg-string - compile a string to a nonterminal
match-peg - match a peg to a string, starting at the beginning
search-peg - match a peg to a string, starting at each index in turn
until we find a match or reach the end

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.

The verb comes first in all of these because I think putting 'define'
in the beginning of syntax that defines things is standard, and then I
made the other names to match that one. If anyone has better ideas,
though, I'm not attached to these names.

Looking forward to merging this,
Noah

Re: Names for PEG Functions

[Andy Wingo]

Hi,

On Wed 21 Sep 2011 22:13, Noah Lavine <noah.b.lavine@gmail.com> writes:

> 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.)

Also, are the different `accum' things necessary?  Just wondering.
Unused bindings will probably be removed by the optimizer.

> 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 ?

> 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 ?

> 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.

> Looking forward to merging this,

Yeah!

Andy
-- 
http://wingolog.org/

Re: Names for PEG Functions

[Noah Lavine]

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

Re: Names for PEG Functions

[Noah Lavine]

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
>

Re: Names for PEG Functions

[Andy Wingo]

Hi Noah,

On Mon 03 Oct 2011 20:21, Noah Lavine <noah.b.lavine@gmail.com> writes:

> 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?

Have you updated the wip-peg branch?  I don't remember who is waiting
for whom any more, but reviewing the threads, it seems that we generally
agreed on some name changes here.

Andy
-- 
http://wingolog.org/

Re: Names for PEG Functions

[Andy Wingo]

On Wed 04 Jan 2012 19:12, Andy Wingo <wingo@pobox.com> writes:

> On Mon 03 Oct 2011 20:21, Noah Lavine <noah.b.lavine@gmail.com> writes:
>
>> 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?
>
> Have you updated the wip-peg branch?  I don't remember who is waiting
> for whom any more, but reviewing the threads, it seems that we generally
> agreed on some name changes here.

A kind ping here :)  It would be lovely to get the peg stuff in for
2.0.5.

Andy
-- 
http://wingolog.org/

Re: Names for PEG Functions

[Noah Lavine]

Sorry for the delay.

I haven't thought about the PEG stuff in a long time, but looking
back, I'm pretty sure I didn't change the names yet. I will try to do
it tonight (in GMT-5). I agree, it would be great to have the PEG
stuff finished.

On Thu, Jan 19, 2012 at 4:53 AM, Andy Wingo <wingo@pobox.com> wrote:
> On Wed 04 Jan 2012 19:12, Andy Wingo <wingo@pobox.com> writes:
>
>> On Mon 03 Oct 2011 20:21, Noah Lavine <noah.b.lavine@gmail.com> writes:
>>
>>> 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?
>>
>> Have you updated the wip-peg branch?  I don't remember who is waiting
>> for whom any more, but reviewing the threads, it seems that we generally
>> agreed on some name changes here.
>
> A kind ping here :)  It would be lovely to get the peg stuff in for
> 2.0.5.
>
> Andy
> --
> http://wingolog.org/

Re: Names for PEG Functions

[Noah Lavine]

I've run into trouble because of my problems building master. I'll
have to work around that, so it won't happen tonight.

On Thu, Jan 19, 2012 at 8:54 AM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
> Sorry for the delay.
>
> I haven't thought about the PEG stuff in a long time, but looking
> back, I'm pretty sure I didn't change the names yet. I will try to do
> it tonight (in GMT-5). I agree, it would be great to have the PEG
> stuff finished.
>
> On Thu, Jan 19, 2012 at 4:53 AM, Andy Wingo <wingo@pobox.com> wrote:
>> On Wed 04 Jan 2012 19:12, Andy Wingo <wingo@pobox.com> writes:
>>
>>> On Mon 03 Oct 2011 20:21, Noah Lavine <noah.b.lavine@gmail.com> writes:
>>>
>>>> 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?
>>>
>>> Have you updated the wip-peg branch?  I don't remember who is waiting
>>> for whom any more, but reviewing the threads, it seems that we generally
>>> agreed on some name changes here.
>>
>> A kind ping here :)  It would be lovely to get the peg stuff in for
>> 2.0.5.
>>
>> Andy
>> --
>> http://wingolog.org/

Re: Names for PEG Functions

[Noah Lavine]

I did the renames. I had to push them as a new branch,
'wip-peg-fixed-2', because I also rebased on a more recent version of
master to avoid some build problems. However, the peg patches are
independent of everything that's been happening in master and
stable-2.0, so they should apply to both branches cleanly (except
possibly for merging the makefiles).

The new names are:

define-peg-pattern: define a nonterminal from an s-expression
define-peg-string-patterns: define many nonterminals from a string
match-pattern: see if a nonterminal matches a string
search-for-pattern: see if a nonterminal matches a string, starting at
each successive offset until a match is found or you reach the end
compile-peg-pattern: turn an s-expression or a string into syntax
which defines a parser for the given pattern

The only weirdness I can see is that we don't really need two
define-peg-* things, because the macro could just detect whether it
got a string or an s-expression and do the right thing. I can fix that
if other people think it should be done.

Noah

On Thu, Jan 19, 2012 at 10:18 PM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
> I've run into trouble because of my problems building master. I'll
> have to work around that, so it won't happen tonight.
>
> On Thu, Jan 19, 2012 at 8:54 AM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
>> Sorry for the delay.
>>
>> I haven't thought about the PEG stuff in a long time, but looking
>> back, I'm pretty sure I didn't change the names yet. I will try to do
>> it tonight (in GMT-5). I agree, it would be great to have the PEG
>> stuff finished.
>>
>> On Thu, Jan 19, 2012 at 4:53 AM, Andy Wingo <wingo@pobox.com> wrote:
>>> On Wed 04 Jan 2012 19:12, Andy Wingo <wingo@pobox.com> writes:
>>>
>>>> On Mon 03 Oct 2011 20:21, Noah Lavine <noah.b.lavine@gmail.com> writes:
>>>>
>>>>> 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?
>>>>
>>>> Have you updated the wip-peg branch?  I don't remember who is waiting
>>>> for whom any more, but reviewing the threads, it seems that we generally
>>>> agreed on some name changes here.
>>>
>>> A kind ping here :)  It would be lovely to get the peg stuff in for
>>> 2.0.5.
>>>
>>> Andy
>>> --
>>> http://wingolog.org/