[mercury-users] Mercury example programs

[brogoff]

On Fri, 17 Jun 2005, Ralph Becket wrote:

> brogoff, Thursday, 16 June 2005:
> >
> > xml.m uses parser combinators. Is that the idiomatic Mercury approach? I
> > ask because even though I've seen parser combinator libraries for ML, in
> > my experience they aren't used; rather lex/yacc or (in OCaml) stream pattern
> > matching (just a nice syntax for hand coded recursive descent parsing)
> > is used.
>
> No, that's just the approach Tom took when he wrote xml.m.
>
> Recursive descent parsers are very easy to write.  Indeed, there is even
> syntactic sugare for just this purpose: if you look up DCG syntax in the
> reference manual and search for examples on the web (it's something
> Mercury borrows from Prolog).

How about some examples in the tutorial using DCGs to implement a simple
recursive descent parser?  Simply elaborating on the calcutator in the
samples directory would be sufficient. As I said, a simple interpreter
that reads from a file is a great practical example.

> > lex.m is a library module rather than a lexer generator. Yet there is a
> > yacc like parser generator, moose.
>
> Coming Real Soon Now are elk and caribou, which are Mercury equivalents
> of yacc and lex.  moose is fine, but apparently has a few awkwardnesses
> that made it easier to start a new design from scratch.

Those would be good, since yacc and lex do have a place, but I'd be happy
with more documentation on the Prologish way to do it.

> > > If you have specific examples in mind, I'd like to hear about them.  I
> > > think the tutorial could be usefully extended with some more realistic
> > > example programs.
> >
> > I'll try and come up with some data munging examples in the field that
> > I work in (EDA) as I develop familiarity with Mercury, but you're
> > certainly right about extending the tutorial. Mercury is unfamiliar to those
> > without a Prolog background, so that tutorial is where many of us will go
> > first.
>
> Actually, Mercury is unfamiliar to those *with* a Prolog background!  I
> think Mercury is more like ML without the imperative parts, augmented
> with ground unification and backtracking from Prolog.

Interesting view. Since Prolog is dynamically typed, coming from ML gives you
the basics of the type system. Minor rant: field names of discrimnated unions
must be unique in a module. One of the things that annoys Caml programmers
(well, one of them, anyways) is the restriction that record field names in a
module must be unique. I'm sorry that Mercury shares the same restriction.
Also, the ability to do record update on multiple fields with one expression is
quite valuable, so hopefully the comment in Sec 3.4.2 applies to a near future
release. Beyond the basic type system, Mercury resembles Haskell more than ML,
with type classes rather than parameterized modules.

At the core though, Mercury seems to owe more to the Prolog and logic
programming tradition than to the ML or Haskell one, and it's that
logic/constraint aspect, combined with the fact that I prefer statically typed
languages, that make it interesting to me.


> > As a specific tutorial example, I am partial to ones that include a
> > simple or medium complexity recursive descent parser. Interpreters are
> > great, as they are simple enough to be easily understood, invoke
> > enough of the IO features of the language to be broadly interesting,
> > and they provide a skeletal framework for modification. The parser in
> > xml.m is a nice example, but I wonder if the parser combinator
> > approach is what the Mercury programmer in the trenches would use.
>
> Well, I've dabbled with Parser combinators, but recent experiments
> indicate to me that recursive descent is the right tool in most
> situations.

I've come to the same conclusion, and I think it's true for lex/yacc and kin as
well as parser combinators. Lex and yacc are fine for knocking up a quick
front end, but handling errors is easier with a well written RDP. IMO, of
course, no flame intended here.

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