Re: Names for PEG Functions
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 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 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 wrote: >>> On Wed 04 Jan 2012 19:12, Andy Wingo writes: >>> On Mon 03 Oct 2011 20:21, Noah Lavine 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
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 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 wrote: >> On Wed 04 Jan 2012 19:12, Andy Wingo writes: >> >>> On Mon 03 Oct 2011 20:21, Noah Lavine 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
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 wrote: > On Wed 04 Jan 2012 19:12, Andy Wingo writes: > >> On Mon 03 Oct 2011 20:21, Noah Lavine 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
On Wed 04 Jan 2012 19:12, Andy Wingo writes: > On Mon 03 Oct 2011 20:21, Noah Lavine 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
Hi Noah, On Mon 03 Oct 2011 20:21, Noah Lavine 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
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 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
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
Hi, On Wed 21 Sep 2011 22:13, Noah Lavine 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/
