[mercury-users] Mercury in academic teaching?

[Jörg Roman Rudnick]

Jonathan Morgan schrieb:
> On 07/10/06, Nicholas Nethercote <njn at csse.unimelb.edu.au> wrote:
>> On Sat, 7 Oct 2006, Jonathan Morgan wrote:
>>
>> >> Is Mercury an option as introduction to logic programming?
>> >
>> > 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.  The main one is very simple - Mercury was not
>> > designed for simplicity, but rather for performance and large-scale
>> > Software Engineering.  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.  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.
>>
>> I disagree.  I studied Prolog first, but didn't properly understand 
>> it until
>> I learnt Mercury and learnt explicitly about modes and determinism;  
>> it was
>> only then I understood what Prolog was doing.
>
> 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.

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

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

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


Cheers,

          Nick


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