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

[Peter Wang]

On 2009-09-29, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> 
> 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.

I don't think there's anything to be worried about.  As the parsers are
concerned, the mutables don't exist and can't affect execution.

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

As the parsers are hand-written, you can't rule out left factors
between B, C and D.  It seems to me like using a cut when you "know"
there are no more solutions.

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

Perhaps fail_with_message should take a univ.  Then you would be able to
provide a structured data representation of the context.  Building up
that context would not be pleasant, though.

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