[m-rev.] Re: for review: parsing_utils improvements

[Ralph Becket]

Ian MacLarty, Tuesday, 29 September 2009:
> > I guess what I'm looking for here is a demonstration that your changes
> > make it noticably easier to handle errors than with the existing
> > interface.
> 
> Consider this partial sparql (http://www.w3.org/TR/rdf-sparql-query/)
> parser that I wrote.  I've attached a copy of the old version which
> uses a result type to keep track of errors (sparql.m).  I've also
> attached a reworked version (sparql.m.new) using the new error handling.
> It is considerably shorter and would have been much less of a pain to
> write.
> 
> If you can tell me a better way to implement the error handling using
> the old system, then please let me know.

I'm trying to work out why throwing an exception at the point you
identify an error won't do the trick for you.  sparql.m.new only has
two calls to fail_with_message.

Ah, now I see: if you want to parse A | B | C and A reports an error,
you want to try B and C to see if you get a parse before reporting an
error.  This makes sense if your grammar isn't LR(k).

Okay, I think I'm happier with your scheme now.  However, it would be
better to have two mutvars, one for the offset and one for the
maybe(error), to avoid the need for an allocation every time you call
record_progress.

Having said that, aren't grammars like this fairly rare?  I mean,
can the mutable stuff be separated out just for the parsers that need
it?

-- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------