[mercury-users] Mercury in academic teaching?

[Peter Schachte]

On Mon, Oct 09, 2006 at 10:09:09AM +1000, Ralph Becket wrote:
> Jonathan Morgan, Saturday,  7 October 2006:
> > As a student who is just studying Prolog, I do not believe that
> > Mercury is likely to be a good introductory logic programming language
> > for several reasons.

I've thought several times about switching from Prolog to Mercury for
this subject, but at the moment, I don't think Mercury is ready to use
in second year teaching.  Mercury has too many sharp edges on which
students can nick (or impale!) themselves.  Prolog certainly has its
share of quirks, but it is a much simpler language.  And just as
importantly in the age of instant gratification, with Prolog you get a
payoff sooner than you do with Mercury, even if ultimately the payoff
is a lot greater with Mercury.  If there were, to badly mix my
metaphors, a version of Mercury with training wheels, that let you
learn the language a bit at a time, hiding the parts you haven't
gotten to yet, and making it easier to understand the part you are
trying to learn, I'd love to switch to Mercury.

For example, take nondeterminism.  On first thought, Mercury seems
like much better language for teaching nondeterminism.  It *forces*
you to think through the determinism of each mode of each predicate,
and then makes sure the code has the expected determinism.  But the
cost of this is that you have to explain modes and determinism before
you can do anything.  And that forces you to explain Mercury's switch
detection algorithm, because some students are sure to run into cases
where Mercury fails to detect determinism.  Student:  "Why is this
definition of min/3 nondeterministic?"  Me:  "Because both clauses can
succeed."  "But in that case, the results are the same.  No matter
what, there's only one solution."  "But Mercury counts it as two."
"Oh...  OK, I fixed it; now why does it think it's nondeterministic?"
"Because Mercury doesn't know that X=<Y and X>Y can't both succeed."
"I see....  Alright, why doesn't this one work?"  "No, sorry, Mercury
can't tell that X<Y and not(X<Y) can't both succeed."  "Pthft."

In Prolog, the first definition would have compiled and run just fine,
although it would leave a useless choicepoint.  Later in the semester,
we explain efficiency concerns and how to get rid of unnecessary
choicepoints, but in Mercury it has to be explained just to get code
to compile.  And in many cases, they can get away without fixing it
at all in Prolog (it is just performance, after all).

Another problem with Mercury for teaching is the flip side of one of
its great features:  once you get your code through the compiler, it
probably works.  The unspoken catch is that you better have set aside
a lot of time, a lot of coffee, and a good set of manuals (and having
access to the Mercury developers is *very* helpful, too) to *get* your
code to compile.  As frustrating as it is to try to figure out why
your Prolog code is failing or looping, it's much more frustrating to
be faced with dozens of error messages from the Mercury compiler, and
worse still to see the number of errors drop to 8, then to 3, then 1,
only to see it leap back up to dozens as the Mercury compiler gets to
the next stage.  I expect if we used Mercury for undergraduate
teaching, we'd be finding large tufts of hair around the labs.

> In favour of Mercury as a pragmatic teaching choice is the lack of an
> interpreter: having strict, static checking by the compiler means that
> users are far less able to "debug" code by making random changes.

Whoa, I strongly disagree there!  The Prolog top level is very useful
in lectures to show how Prolog works.  Having to type in, compile, and
run a 10 line program to do a one line test is very unweildy.
Similarly when developing:  I find it *much* easier to test code
bottom-up in Prolog than in Mercury, since you don't have to build a
test scaffolding.  Nor do I see how the lack of a top level in any way
discourages "change something and try again" development.  Once you've
built the scaffolding to test your Mercury code, if it doesn't work,
why would you be any less likely to just change something and try
again?  I know I've done that in Mercury when I couldn't figure out
what the compiler's error messages were trying to tell me.

> I don't think that many subtle issues have to be mastered by Mercury
> beginners.

When you're explaining things, I agree you can gloss over details.
But as soon as you turn students loose in the lab, they will quickly
run into some of the huge body of subtleties you have to understand to
develop code in Mercury.


-- 
Peter Schachte              A problem well stated is a problem half-solved.
schachte at cs.mu.OZ.AU            -- Charles Kettering 
www.cs.mu.oz.au/~schachte/  
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------