[mercury-users] Parsers in Mercury

Dan Hazel d.hazel at mailbox.uq.edu.au
Thu Sep 23 11:42:00 AEST 1999


You have options:
Either
    1) Make some grubby annotations outside Mercury (in C perhaps).
or
    2) Don't fail.  Don't backtrack.
       I imagine you're threading a token list through your parser?
       Instead thread a structure which contains your token list and
       some other information - something like:
           
:- type parse_stack --->
    ps(
        list(token),          % current token list
        int,                  % depth
        int,                  % depth of best error
        list(string),         % message of best error
        list(parse_stack)     % pushed parse_stacks
      ).

       At each legal token, increment "depth".
       At the start of each production, "push".
       At the successful end of each production "pop".
       At an error, "pop" and if "depth" is > "depth of best error"
           update "depth of best error" and "message of best error".

       This approach will also require wrapping the structure output
       by each production in something like:

:- type report(T) ---> ok(T) ; error.

       where error could be more elaborate - maybe:
           error(list(string), int, list(token)).

I've used 2) successfully in the past though
I must say after all that, 1) looks much more tempting :-)

hope this helps,
Dan Hazel

ps feel free to get in touch outside the list if the above is too muddy.

Gilbert Roulot writes:
 > 
 > I have been writing a parser in mercury for a rather simple file format
 > (one command per line, little or no ambiguity).I managed to make
 > something that'll understand files that have no error in them and I
 > though I might as well add error detection and report to it (missing
 > tokens, token that shouldn't be here, etc.) 
 > 
 > The problem is there, I'm having a lot of trouble doing that ; I have
 > changed the implementation several time and it's *only* nearly working.
 > I searched for paper on parsers (for a better architecture) on the
 > internet, but most deals with functionnal language like Haskell
 > Before I continue and try to use these information for yet another
 > mutation of my parser, I'd like to know if Mercury's nature (it has
 > backtraking) affect the way people write parsers in it, compared to
 > functionnal language. Any document on this ? Or source code I could
 > study ?
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list