[antlr-interest] Serious doubts on usage of incremental parsinginides

John D. Mitchell johnm-antlr at non.net
Tue Apr 26 11:38:51 PDT 2005


>>>>> "Prashant" == Prashant Deva <prashant.deva at gmail.com> writes:
[...]

>> Depends on how tightly you need/want to constrain the synchronization of
>> the various views.

> exactly, so if u have to update everything else so late only, then why
> run an incremental parser. why not run a batch parser?

Why do you keep asking the same question?  You tell me why you think you
should run an incremental parser in that case.  If you don't need the tight
constaints then there's no need for a true incremental parser.  If you do
need the constraints then you've got some issues to work out in terms of
e.g., the tradeoffs.


>> For some situations, people do really want the system to be extremely
>> strict.  Though, in most of those cases that come immediately to mind,
>> the interface is relatively simple.

>> Of course, in those really strict cases, I don't know that I'd call them
>> incremental parsers as much as I'd call them extremely constrained
>> editors.

> You dont seem to get the meaning of an 'incremental parser'. an
> incremental parser is one which will produce exactly the same output as
> that of a batch parser but it parses just the modifications and leaves
> the rest of the stuff as is.  Thus a good incremental parser (like mine
> ;) ) should allow an unrestricted editing model and should recover from
> errors eaxctly as a batch parser would.

No, I understand quite well what a true incremental parser is, that's why I
made that comment.  Most reasons that I've heard that people want a true
incremental parser is because they have some need/desire for very tightly
constrained limits on e.g., what the user can do any any given point.  In
all of the other cases, people yack endlessly about 'incrementalism' but
don't really want any constraints and run into the same connundrum that you
have.

Take care,
	John


More information about the antlr-interest mailing list