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 <address@hidden> 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
>