[mercury-users] Mercury in academic teaching?

[Jonathan Morgan]

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 suspect that you are better to teach Prolog, expose the
problems with it, and then the student will be able to see some of the
reasons behind the design decisions.  For example, the I/O state and
similar "pure" constructs enable us to re-order code in a logical
manner, which Prolog cannot do.  At various places learning Prolog
there are non-logical work-arounds that are necessary - I look at most
of these and think that Mercury handles them far better (without
work-arounds).  A few examples are cc_multi rather than
if-then-else/cuts for determinism, and re-ordering rather than var and
friends to make multiple modes work.

> 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.  Also,
> Mercury's mode system provides a useful handle on the operational
> semantics of programs.

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.

> > The main one is very simple - Mercury was not
> > designed for simplicity, but rather for performance and large-scale
> > Software Engineering.
>
> I don't think that many subtle issues have to be mastered by Mercury
> beginners.  I think problems understanding determinism cause most
> problems for beginners, but determinism is also the main source of bugs
> in Prolog programs.  I think it is easy to write programs that do
> something in Prolog; however, it is much harder to write programs that
> do what you intended.

I would agree with most of that.

> > In my opinion, this makes it a great language
> > for using to write real programs, but not for education, as even small
> > programs require understanding of Mercury's module system, type and
> > mode system (unless you use inference), and the I/O state.
>
> Mercury's type system (as far as beginners are concerned) is
> considerably simpler than that of C or Java.

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

> 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.  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).

> 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).

> In general, I'd say you could just give beginners template Mercury
> programs with "/* your code goes here */" comments for them to fill in.
> They'd get the hang of things pretty quickly.

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?

> > On the
> > contrary, most Prologs do not require types, and have interpreters,
> > allowing them to be used in an exploratory manner quickly and easily -
> > which I feel is much better for education as an introduction to logic
> > programming.  Prolog is much simpler (and probably more elegant) for
> > writing small programs in, and for playing round with to discover how
> > things like non-determinism work.
>
> Hmm.  In my years of using and teaching Prolog, I think the interpreter
> inclines people to solving problems by making random code changes rather
> than using their brains.

Possibly.  I have never used it that way.  However, what I like about
an interpreter (with a small program) is the ability to see what
happens when I change my queries for a predicate that I am willing to
rely on the rules (e.g. pred(3, X) gives only one solution.  I wonder
what pred(X, 3) gives?).  If it is being used for random debugging I
would agree that it is undesirable.

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