[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Names for PEG Functions
Re: Names for PEG Functions
Thu, 22 Sep 2011 13:56:53 -0400
>> 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.