[mercury-users] Error detection rate in Mercury vs Other Languages (esp C++ and Python)

[Chris King]

On Fri, Dec 2, 2011 at 12:35 PM, Tomas By <tomas at basun.net> wrote:
> On Fri, December 2, 2011 18:12, Chris King wrote:
>> I'd like to chime in though that Mercury's failure model lets a
>> particularly pernicious class of bugs slip through easily; namely,
>> those bugs in which you expect a result from some predicate but
>> receive none, i.e., a predicate is failing for the wrong reason.
>> [...]
>> Of course, this is a problem not just with Mercury, but with logic
>> languages in general.  Prolog is probably the worst offender, having
>> no notion of checked determinism.
>
> After reading this I feel a certain morbid curiosity about what some
> significant amount of Mercury code written by you would look like...
>
> When I was writing non-trivial pieces of code in Prolog these were
> probably the most annoying bugs I was having. You finally finish all
> your various modules, get your data sorted out, and try to run the
> whole application for the first time. Prolog answers: "no"

I try to write Mercury as if it were Prolog.  Otherwise you're just
writing Clean/Haskell/OCaml/what-have-you.

A good example is a C99 parser I developed for my blog:
http://adventuresinmercury.blogspot.com/2011/10/parsing-expression-grammars-part-2.html

Since every DCG predicate is necessarily semidet with a ground input
argument (the parser state), all too often while testing, my main
function just printed "Failure!" instead of a parse tree, due to the
spurious failure of some predicate or other.

(I know a real parser would have better error detection, but I want to
be able to catch bugs during development, not after.)

Another example, again from my blog (though not yet posted) is a
checkers-playing AI.  The move-generation predicate is necessarily
nondet, since it is possible that there are no moves from a given
state.  But while testing I found several spurious failures due to
accidental incorrect usage of the map API.  It would have behooved me
to use require_det in this case.

Another possible approach in this case would be to extend the map
module to include higher-order insts for maps, so I could then declare
a multi mode for the move-generating predicate for some instantiation
I know to have possible moves.

Of course I could write the move predicate as a det function returning
a list and litter my code with lists, maybes, and bools, but then I'd
be reinventing monads and writing Haskell code.

> If you declare the mode of all your predicates

Doesn't help if you intend your predicates to be semidet (see above).
What does help in some cases is to declare at least one det mode for a
specific instantiation of the input arguments, but this is not always
possible (again, see above).

> and use non-determinism as sparingly as possible

In that case you're just writing Haskell code.  Beside,
non-determinism isn't the issue, it's failure.

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------