[mercury-users] cost/benefit analysis of non-determinism in Mercury

[Nicholas Nethercote]

Hi,

One of Mercury's distinguishing characteristics is its support for
non-determinism.  However, my gut feeling is that people using Mercury for
writing real, large programs use non-determinism very little.  Can anyone
estimate the number of predicates in the Mercury compiler (or other large
Mercury programs) have a non-deterministic procedure?

This led me to wonder:  if one removed non-determinism from Mercury, how
much simpler would the implementation (compiler, debuggers, profilers,
runtime system) be?  In terms of lines of code, and general
understandability and maintainability.

Also, would it help generated code at all?  I would guess not, thanks to
the different code generation techniques for det/semidet/nondet
procedures, but maybe the story isn't so simple?

This thought came from me thinking about Haskell, which I think is a great
language -- pure, statically typed, functional -- except for the default
laziness, which I consider an unfortunate evolutionary hangover, rather
than a good feature.  Mercury is also pure, statically typed, functional;
it also has a feature (non-determinism) that, to me, is a baroque remnant
of its heritage, albeit one that's far less intrusive than Haskell's
laziness.

Drifting off-topic, I wonder how many people have been put off learning
Mercury because they thought it was like Prolog?  Ie. pigeon-holed it as a
"logic/AI" language, rather than a general-purpose language.  In my
experience, lots of people are very dismissive of Prolog.

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