[mercury-users] Mercury in academic teaching?

[Peter Schachte]

On Tue, Oct 10, 2006 at 11:22:57AM +1000, Ralph Becket wrote:
> I agree there will always be a certain section of a class who take this
> approach.  However, it is harder to get wobbly code past the Mercury
> compiler: it isn't a language for the hack-and-hope types.

People hack-and-hope when they don't understand why what they're doing
isn't working.  Certainly many students find Prolog inscrutable, and
they may cast about trying their best guess solutions (eg, inserting
cuts, which is why I don't cover cut in my teaching).  But I know I've
found some Mercury compiler error messages inscrutable, and cast about
hacking and hoping to figure out what was wrong.  The difference, as
Richard pointed out, is that when Prolog is doing something you don't
expect, you can usually use the debugger to figure out why.  OTOH,
when you can't understand the error messages from the Mercury
compiler, there's nothing you can do except cast about taking your
best guess and changing things, unless you can find someone who
understands it and can explain it to you.  The Prolog debugger can
*teach* you how Prolog works, so you don't make the same mistake
again.  There's no similar tool for the Mercury compiler's error
messages.

> My position is that while Prolog is definitely a simpler, more forgiving
> language, in order to write reliable programs you still have to
> understand modes and unification and determinism.

Eventually, yes.  But you can get a good week or two into Prolog
before covering those things, and they can be introduced one at a
time.  It's harder to ease into Mercury, and Mercury is less able to
explain itself to you the way the Prolog debugger explains Prolog.

> ... in many cases the compiler tells you when
> your program is not going to do what you thought it would.

Absolutely...once you completely understand Mercury well enough to
understand what the compiler is telling you.

As I said before, Mercury with Training Wheels (TM) would be a great
teaching language.  It would start out like pure untyped higher-order
Prolog with proper unification and runtime errors when things go
wrong.  But it would allow you to gradually restrict yourself with
strong types, modes, determinism, mode-sensitive higher-order
programming, etc., so execution is efficient and things can't go wrong
at runtime.  Once you've seen what can go wrong, and understood it
through the debugger, then you're ready to understand those compiler
error messages.

-- 
Peter Schachte              Certainly there are things in life that money
schachte at cs.mu.OZ.AU        can't buy, but it's very funny -- Did you ever
www.cs.mu.oz.au/~schachte/  try buying them without money?
Phone: +61 3 8344 1338          -- Ogden Nash 
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------