I too became principally interested in PEG as an alternative to regular expressions: in spaces where they're frequently used to create ad-hoc parsers for small "languages" (like validating an email address or, searching a semi-structured logfile. It's been my hope also that various PEG implementations could accept the same literal grammars and interpret them at runtime, so that libraries of these things could be shared.
-- Jeremy On Aug 8, 2011 9:41 PM, "Joe Strout" <j...@strout.net> wrote: > On 8/8/11 6:11 PM, Francisco Mota wrote: > >> You are correct in assessing that .+ and .* expressions will probably >> never be useful. PEGs are completely different from regular expressions >> -- don't be misled by the syntactic similarities. > > Fair enough. > >> To answer your first question, "Why should the repetition operators be >> greedy by default?" >> >> Because there is no backtracking*. So X* would always match the empty >> string, and X+ would always match X. > > Ah. Without backtracking, that would be true. And as you point out: > >> In PEGs, there is a property of any parsing expression, and it is >> this: a parsing expression has only one possible match for any given >> string. This property enables packrat parsing. If you add backtracking*, >> you throw this property away. > > Doh. So we lose the linear parse time guarantee. It still might be > worth it, for string searching (as opposed to language parsing), but I > see now that the result would not be PEG in important ways. > > Thanks, > - Joe > > _______________________________________________ > PEG mailing list > PEG@lists.csail.mit.edu > https://lists.csail.mit.edu/mailman/listinfo/peg
_______________________________________________ PEG mailing list PEG@lists.csail.mit.edu https://lists.csail.mit.edu/mailman/listinfo/peg
