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

[Ralph Becket]

Ian MacLarty, Tuesday, 29 September 2009:
> On Tue, Sep 29, 2009 at 4:02 PM, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > Ian MacLarty, Tuesday, 29 September 2009:
> >> > 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?
> >>
> >> I don't know. What did you have in mind?
> >
> > Well, my sparql parser might simply define its own mutable and implement
> > its own fail_with_error predicate.  The position only needs to be
> > recorded at the point where fail_with_error is called.  If the parser
> > succeeds at a point further than that stored in the mutable, then the
> > error therein can be ignored.
> >
> 
> Yes I suppose you could do that, but I think that puts too much burden
> on the parser writer since they would have to write all the impure
> code to manage the mutable.  The point of this change is to put that
> behind an abstraction barrier so users don't shoot themselves in the
> foot.
> 
> Also with this change you don't actually have to call
> fail_with_message at all to get a usable error report.  Even if you
> never call fail_with_message you can still get the furthest offset the
> parser got to before it failed, which is a lot more useful than no
> information at all.
> The idea is that users could write their parser in a naive style and
> still end up with something that is usable.

My main concern with this change is that I'm not convinced it's the
right way to do things.  Sticking mutables in there always starts
alarm bells ringing.  I may be wrong.

Here's the thing: say I have a rule

A ::= B | C | D
B ::= B1 B2 B3
...

If I'm parsing A and B1 succeeds, then, in virtually all grammars
I've seen, if B2 B3 fails then I know this is an error and I know
C and D shouldn't match (if they can then I have a fairly unpleasant
grammar...).

The question now is, if B2 B3 fails, what should I do?  My first
thought is throw an exception.  Exception handlers further up the
call stack can try advancing the offset until the next sensible
starting point if we want to search for more errors.

The other problem I have with this approach is that when I want to
report an error, I usually want to provide more context.  For example,
I'd like to say

	In application of foldl
	In argument 1
	This is not a function.

rather than

	Expected a function at line 27 column 16.

I don't see how the proposed scheme would make this kind of error
reporting easier.

I agree that error support is something we should add, I'd just like
us to explore the design space more before committing to anything.

-- 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
--------------------------------------------------------------------------