[mercury-users] Mercury in academic teaching?

[Jonathan Morgan]

On 08/10/06, Jörg Roman Rudnick <joerg.rudnick at t-online.de> wrote:
> Jonathan Morgan schrieb:
> > Whereas I had the opposite experience - I read Ralph's tutorial, and
> > played with Mercury (coming from a Haskell background), but I didn't
> > really understand how Mercury worked (or even why various issues were
> > cared about) until doing a couple of weeks of Prolog, just playing
> > with the SWI interpreter and experimenting.  If I wished to have
> > multiple solutions, I could get them one at a time from the
> > interpreter, examine them, and figure out what was happening.
> >
> > On the other hand, knowing Mercury makes me annoyed at all the various
> > "solutions" proposed to Prolog problems, which Mercury can handle
> > automatically.
> >
> >> I don't think Mercury's module system is difficult at all
> >> (particularly if
> >> you're writing single-module programs), and the I/O isn't that
> >> difficult --
> >> it's much simpler than Haskell's and Haskell is routinely taught to
> >> computer
> >> science novices.
> >
> > I was not arguing that it was more difficult, just that it was another
> > thing that had to be done before you could even get your first
> > programs working.  I'm also not convinced that Haskell's model of I/O
> > is all that difficult to use (as opposed to reasoning about it).  If
> > you use the do syntax, all you need to know is that your instructions
> > will be carried out in the order specified, that some kind of action
> > occurs, and that if you wish to get input you need to use <- rather
> > than =.  Mercury takes far too long to get to the stage where you can
> > just play with the language and see what happens if you change this,
> > that or the other.
> >
> > I have found (for both Prolog and Haskell) that having an interpreter
> > is a great aid in learning a language initially.  The ability to alter
> > your queries and get a result without having to worry about providing
> > a main, and without having to re-compile for every tiny little change,
> > helps me in figuring out what is happening.  The ability to put
> > together an exploratory prototype, without having to work out exactly
> > what the type system expects from you, is very useful (though Hugs was
> > strongly typed as well as interpreted).  On the other hand, I would
> > not wish to write serious programs in Prolog - I use the type system
> > of Mercury heavily, and am convinced that a program does not have to
> > grow very large before the disadvantages of Mercury for exploratory
> > programming become irrelevant, as the disadvantages of exploratory
> > programming come to the front.  I like many of Mercury's features,
> > designed for software construction in the large, but I do not think
> > that they are appropriate for introductory logic programming.
> >
> Our students are bred with Java, so they should be quite accustomed to
> accepting some baroque syntax surroundings in the beginning - just
> imagine 'HelloWorld' in Java - what is the meaning of 'System', 'out',
> 'public', 'static', ...? C# is no big difference.

Which is why I don't like using Java as an introductory language, for
much the same reasons.

> Programming in interpreted mode is not familiar to our students. To be
> honest, you need a lot of good will to regard as serious most of the
> existent interpreter shells (e.g. lack of cursor navigation, history, ...).

I don't find either hugs or SWI too bad - though they are certainly
not brilliant.  However, I am not advocating writing programs in the
interpreter, just using it as a tool to experiment with rules which
will have been written separately without using the interpreter.

> But there is another point to mention:
>
> In our case, I would say the richness of syntax - that's the positive
> side of it - would rather be an argument in favour of Mercury: Our chair
> holder has considerable interest in functional programming and even ADA,
> but had to make a comprimise as we are only able to introduce one
> language (Mercury was not known at this moment) - Prolog made it because
> introducing the greatest amount of new concepts in comparision to known
> OO languages.
>
> In that case, Mercury offers the chance to teach a great number of
> programming concepts without having to learn different languages - quite
> attractive, if you are somewhat limited in teaching time.
>
> I agree that Prolog is simpler - as long as you skim it in a more
> 'theoretical' approach (genealogy etc...), but it tends to become
> confusing when you are trying to write programs doing real things -
> runtime behaviour is difficult to predict. As our chair holder is
> somewhat into finite domain constraints, time expense was in
> consideration at some places, what often led to just guessing for an
> efficient solution.
>
> And, of course, we wish to do projects that do develop some useful
> applications...

If the project is large enough, Mercury is a better choice.  If
efficiency is important Mercury is also probably a better choice
(though, from memory, programs that are heavily based on type-class
inheritance and OO design have the potential to be less efficient).

> To mention Ralph Beckett's introduction points at an interesting
> subject: First, you can't blame him for not having finished his work, on
> the other hand I would estimate about 50% of all )o+> features to be
> documented... Personally, I love it, it makes the whole truly
> adventurous... :-) :-) <+o( :-) (note the Mercurian smiley... ;-)
>
> One should not forget the 'unfair' advantage of other languages by rich
> documentation - here I see hope an academic course could recontribute to
> the project...

I don't blame him in the least.  The introduction is very interesting.
 The fact still remains that there is a lot of material on Prolog,
much of which is relevant to Mercury (or can be made relevant with a
little thinking).

The Mercury documentation is very useful - but it requires an initial
rough knowledge of Mercury, Prolog or a functional language like
Haskell.

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