Let's stop parser Hell

[Jonathan M Davis]

On Wednesday, July 11, 2012 08:41:53 Jacob Carlborg wrote:
> On 2012-07-10 22:53, Jonathan M Davis wrote:
> > Well, giving an error, continuing to parse, and giving a partial result
> > can be useful (and you give a prime example of that), but "fixing" the
> > problem (e.g by inserting the semicolon) and not considering it to be an
> > error would be a _huge_ mistake IMHO. And that's essentially what happens
> > with HTML.
> No, that is _not_ what happens with HTML. With HTML, the browser _do
> not_ output the error and continues as if it was valid could. As far as
> I know, up until HTML 5, the spec hasn't mentioned what should happen
> with invalid code.
> 
> This is just a error handling strategy that is an implementation detail.
> It will not change what is and what isn't valid code. Are you preferring
> getting just the first error when compiling? Fix the error, compile
> again, get a new error and so on.

??? I guess that I wasn't clear. I mean that with HTML, it ignores errors. The 
browser doesn't spit out errors. It just guesses at what you really meant and 
displays that. It "fixes" the error for you, which is a horrible design IMHO. 
Obviously, we're stuck with it for HTML, but it should not be replicated with 
anything else.

This is in contrast to your example of outputting an error and continuing to 
parse as best it can in order to provide more detail and more error messages 
but _not_ ultimately considering the parsing successful. _That_ is useful. 
HTML's behavior is not.

- Jonathan M Davis