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

[Paul Bone]

I can't tell if Ian is asking for a nondeterminstic parser (the kind found
commonly in natrual-langauge technology) or an LL(k) parser with a non-trivial
k.  In both cases it's clear the he wants to know why something could not be
parsed which is fair.

It's my understanding that parsing_utils.m is not a nondeterminstic parser and
is never supposed to be one.  Furthermore it's an LL parser where any lookahead
(k) has to be managed by the programmer (parser writer), therefore for an LL(k)
grammar with a large k it's going to be difficult to use parsing_utils to write
a parser, but not impossible.

If you need lookahead, then you need to manage that as the parser writer.  Any
error handling built into parsing utils should, IMHO, be written as if the
grammar is LL1, like the rest of parsing_utils.m.


On Tue, Sep 29, 2009 at 05:25:32PM +1000, Ralph Becket 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.
> 
> 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...).

Yes,  This is either an LL(k) where k>1 gammar, or a nondetermistic 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.

That's going to be language/grammar specific.

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

Is that really a parser error?

I would have thought something like:

file.c:20:13: Parser error, read identifier, expected ')' or ','
          ^^
          Column number within line 20.

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

I agree.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20090930/7f2e7310/attachment.sig>