[mercury-users] Mercury in academic teaching?

[Ralph Becket]

Jonathan Morgan, Monday,  9 October 2006:
> On 09/10/06, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> >Jonathan Morgan, Saturday,  7 October 2006:
> >> On 06/10/06, J?rg Roman Rudnick <joerg.rudnick at t-online.de> wrote:
> >> >are there any experiences with teaching Mercury instead of Prolog at
> >> >academic level?
> >> >
> >> >The head of the chair I'm working at displays unexpected interest in
> >> >Mercury - now a completely new question appears in my head:
> >> >
> >> >Is Mercury an option as introduction to logic programming?
> >> >
> >> >Personally very convinced, I am unsure about possible problems in
> >> >teaching it as second (or third) language besides Java (and C#) to
> >> >students of AI (at a course of study like 'master of business 
> >computing').
> >> >
> >> >I would be very interested in your opinions...
> >>
> >> 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.
> >
> >You can make arguments either way.  For my money, the distinction is
> >
> >- Prolog has full unification, but is not logical (cuts, improper
> >  handling of negated contexts, no occurs check, no distinction between
> >  pure and impure code, etc.)
> >
> >- Mercury is a pure logic programming language, but does not support
> >  full unification (for that you need to use solver types, which are
> >  probably not for beginners).
> 
> Teaching Mercury as a pure logic programming language does not answer
> the why.

I assumed that if you wanted to teach logic programming you would pick a
logic programming language.  You have to have a fairly generous
definition for LPLs to include Prolog.

> I like using the interpreter for small systems, as it enables you to
> query any part of the program without requiring I/O (though trace
> goals might do this a lot better for larger programs), and to use the
> debugger without having to specifically compile for debugging.

Maybe so.  I still think interactive interpreters are oversold.
Students code for C and Java projects without them and don't seem to
suffer.

> And stricter (for example, I can easily see the average student asking
> why this integer can't just automatically go to a float).

It's easier to explain Mercury's rule than, say, coercions in C or C++.

> >IO issues are common to Mercury and Haskell.  You don't have to go into
> >depth about the io-state/di/uo issue, you can simply teach it as "here
> >are the rules you need to understand to do IO".
> 
> You can teach it that way.  I do not think that it is a good way to
> teach it, for the simple reason that it leaves the students wondering
> why it is done that way.

When I taught Haskell to an advanced first year class, declarative IO
was one of the things that they utterly failed to understand.  Many of
them did grasp *how* to deal with IO in Haskell, however.

> If they have studied C/Java or any other
> similar imperative language they will be able to see that those
> languages do not need such a restrictive approach to I/O, so why is it
> necessary here? (maybe I'm just one of those strange students who
> wants to know why various design decisions have been made).

IO is trivial in imperative languages because they are based on side
effects.

Explaining how you can manage IO and other side effects in a declarative
language without destroying the semantics is quite a challenge.  I would
not expect most first year students to understand the reasons.  On the
other hand I would expect most first year students to be able to write
programs that do some IO.

> >The Mercury module system is very simple, moreso than Java's private
> >rules or C's header file conventions.
> 
> True, but it's still one thing more than Prolog needs.  Prolog
> concepts can be introduced fairly nicely by starting with facts and
> introducing rules from there.  I can't see that happening with
> Mercury.  A module system is useless if you only want to work with one
> module (C doesn't require it for one-module programs either).

There is a tradeoff: the extra module/type/mode declarations in a
Mercury program allow the compiler to give you precise and helpful
explanations of why your program is buggy.  Prolog does no such thing:
the primary failure mode of a Prolog program is to silently backtrack
and do something else.

I agree that Prolog has its place and, IMO, that place is explaining
backtracking and unification.  Prolog is not a good vehicle for teaching
logic programming because it pretty much forces you to write non-logical
programs.

> If you were using Mercury I suspect that that would be a reasonable
> approach.  However, how are you going to handle multiple solutions,
> and similar things?

Include it in the template?  I have no problem with supplying the
advanced code for students when I'm trying to get them to do simple
things.

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