[mercury-users] Handy Programming tool for Mercury.

Andrew Bromage bromage at cs.mu.OZ.AU
Fri May 21 17:26:54 AEST 1999


G'day all.

Richard A. O'Keefe wrote:

> I'm baffled.  The only parsing notations I know that come close to DCGs
> for power and convenience are close relatives.  I've used, heck, I've
> even _taught_, parser combinators in Haskell, and they seem to me to
> be (a) clumsy compared with DCGs, and (b) essentially dependent on lazy
> evaluation.  I've used, and taught, Yacc.  If you look around, you'll
> find that most functional languages (ML, Lisp, even Erlang) have some
> kind of Yacc clone available, but with the usual Yacc-ish clusmy error
> handling.  If you want a more powerful technique than Yacc's, there's
> the potentially-infinite-lookahead method used in PCCTS.  But there
> again we are talking about attributed grammars which are really just
> a restriction of DCGs.  The only thing different is the execution
> strategy.

FWIW, I fleshed out a design for a parser generator "in the spirit of
Mercury" a couple of years ago.  It would use a potentially-infinite-
lookahead LR(k) parser partly based on PCCTS ideas but mostly based on
Mark Hopkins' "quantum parsing" formulation.  The idea is to use a
syntax which looks very much like DCGs but is compiled into code which
resembles "Even Faster LR Parsing" except it can use arbitrary lookahead.
Plus, of course, since we're using a logic language, the parser generator
always has the option of producing nondeterministic code if it can't work
out a way to resolve all parsing conflicts.

For some reason this hasn't actually translated into code. :-)

> It seems to me that if you want a superb parsing kit for Mercury,
> you don't need any new *notation*, but you *might* need an alternative
> execution strategy (I have a fondness for left-corner parsing, but
> there are plenty of others) and you will do well to think about
> error recovery (I lack Backhouse's stuff, but that's a bit old by now
> so I suppose there's something better).

Error recovery is one of the reasons there's little code at the moment.
That's one of the issues I'm still trying to work into the design.  One
other is the problem of mode declarations on the attribute grammar.
(That is, how to get the kinds of dataflow you'd want in an AG without
re-implementing the Mercury mode analyser in the parser generator.)

Cheers,
Andrew Bromage
--------------------------------------------------------------------------
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