I don't see the connection of your answer Juancarlo and Francisco's question on incremental parsing.
Who is talking about error recovery? I am not aware of an existing PEG implementation that saves the memoization table in order to allow efficient re-parsing of a slightly altered version of the input. In fact it seems that Packrat is fairly memory hungry, and that attempts are made to drop this table as soon as possible. -- Dinesh Bolkensteyn www.SonarSource.com <http://www.sonarsource.com/> twitter.com/DBolkensteyn On Mon, May 6, 2013 at 4:58 PM, Juancarlo Añez <apal...@gmail.com> wrote: > Hello Francisco, > > On Mon, May 6, 2013 at 9:00 AM, Francisco Mota <fmot...@gmail.com> wrote: > >> Is there an off-the-shelf available incremental parser for PEGs? >> >> Incremental parsing is where a small change in the input string >> necessitates only a small amount of additional processing. The idea is that >> you parse the string once, and then adding or removing characters from the >> string in the middle causes only a small amount of reprocessing. >> > > This is advice I remember from the ANTLR lists, which you can search > online: http://antlr.1301665.n2.nabble.com/ > > > - Add additional, catch-all/catch-some rules at the points in which > you'd like recovery to happen. > > PEG parsers are outstanding at skipping over input. > > For example, in parsing embedded SQL in COBOL, I have a rule similar to > this one for skipping over uninteresting parts: > > skip_uninteresting_sql = {!'END-EXEC ANY} ; > > With "*!*END-EXE" being a negative lookahead for the end-of-statement > word, and "ANY" matching any input character. > > The above is inefficient, but it gives the idea. The actual rule for the > compiler generator I'm using (Grako), uses a perl-style regular expression > that's handled by the Python re library (DFAs), so it's cool: > > skip_uninteresting_sql = ?/(?:.|\n)*?(?=END-EXEC)/? ; > > That regular expression means "match anything until END-EXEC is in sight". > > As we've been discussing on another thread, these kind of techniques are > possible because PEG does not require a tokenizer, so parsers are in > complete control of the interpretation of input stream, even on > character-by-character base. > > Cheers, > -- > Juancarlo *Añez* > > _______________________________________________ > 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
