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

[Chris King]

On Fri, Dec 2, 2011 at 1:57 PM, Tomas By <tomas at basun.net> wrote:
> On Fri, December 2, 2011 19:36, Chris King wrote:
>> (I know a real parser would have better error detection, but I want to
>> be able to catch bugs during development, not after.)
>
> "better" error detection??
>
> Yours have none whatsoever.

No, it's *strictly* an error detector :) it just doesn't give any location info.

> I had this experience that you may soon have some 10-15 years ago, when
> after writing a DCG-style Mercury parser for a non-trivial formalism,
> and spending a week or so debugging it (incompletely), I threw it all
> away, rewrote it in continuation-passing style (I believe it is called),
> and debugged it in 15 minutes.

So, there's two orthogonal issues here: debugging and parser error reporting.

Debugging is easy.  Once you *know* there is a bug, you can just use
the debugger to track it down.  (I would say "declarative debugger"
but I can't get the "dd" command to do anything but quit mdb....)
Therefore, the only improvement CPS can have on this is to catch more
errors at compile time than DCG with require annotations.  Does it do
this?

Parser error reporting is a different beast entirely.  Useful parse
error reporting is nontrivial.  If there's a syntax error in code
somewhere, it's usually a typo, which means that it can be fixed by
very few keystrokes, and a human would like to know what those
keystrokes are.  Hence we have a rough metric: the "correct" error to
report is that which requires the smallest change to fix.

I don't doubt you got more useful parse error messages out of your CPS
parser than I do from my DCG one.  However you did manually that for
which what parser generators were invented, at the expense of
self-documentation (with DCG, the grammar IS the code).

If I'm parsing something a human wrote, then I'd say you came out on
top.  OTOH if I'm parsing something a machine wrote, it's far easier
to know where to place the blame if my DCG (which word-for-word
follows the spec) doesn't parse it.

>> 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.
>
> Just put the state in a data structure and make all the code det.

No, read the rest of my e-mail.  That's what I would do if I were
writing OCaml or Haskell code, and I'd have to resort to monads or
list comprehensions to make the code maintainable.  I find little
point to using a logic language if I'm going to go out of my way to
avoid nondeterminism.

Now *I'm* "morbidly curious" (which BTW is not a good phrase to use to
make friends)... why do you bother to use Mercury if you avoid
nondeterminism and 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
--------------------------------------------------------------------------