[mercury-users] Mercury in academic teaching?

[Jörg Roman Rudnick]

Jonathan Morgan schrieb:
> On 07/10/06, Kathryn Francis <francis at students.csse.unimelb.edu.au> 
> wrote:
>>
>>
>> On Sat, 7 Oct 2006, Jonathan Morgan wrote:
>>
>> > On 06/10/06, Jörg Roman Rudnick <joerg.rudnick at t-online.de> wrote:
>> > > 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').
>> > >
>> >
>> > 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.
>>
>> I'm a lab demonstrator for the subject 'Logic and Computation', which is
>> the subject that teaches Prolog in our department, and I find that 
>> one of
>> the main things that confuses people learning Prolog is the absence of
>> types. I get questions like "How does Prolog know that this is 
>> supposed to
>> be a tree?" all the time.
>
> I have never felt like that - but I always wanted the types in to
> start with, and I suppose I did have experience of Mercury before
> using Prolog.
>
>> It seems to me that you need to think about types and modes to write
>> correct programs in prolog, and it's actually helpful for a novice to
>> write them down explicitly, which is what Mercury forces you to do. Also
>> having more static checking can be useful for novices because you get
>> handy hints from the compiler in cases where the corresponding Prolog
>> program would just fail or give a runtime error.
>
> Some of the hints I have got from the compiler (with both Haskell and
> Mercury) have been anything but handy.  However, I agree that you need
> to think about the types to some extent - but do you really need to
> know about `di` and `uo` modes? (`in` and `out` make fairly good
> sense).  I would certainly prefer the compiler to prove my program is
> deterministic, rather than having the predicate just fail because my
> types were slightly wrong, or produce multiple solutions in wierd
> contexts.
>
>> That said, I think the decision to teach Mercury or Prolog really 
>> depends
>> on exactly what you're wanting to get across. If you just want to teach
>> logic programming concepts, then maybe Mercury is the way to go, but if
>> you want to also introduce students to an interpreted style language
>> geared towards fast development, or you want to introduce a weakly typed
>> language to contrast with Java, then clearly Prolog is better.
>
> Make that 'exploratory development' - my guess is that you can
> probably develop a large software system much faster in Mercury than
> in Prolog, because the language features fairly quickly start becoming
> an aid, whereas in Prolog it is the other way around.
>
> I am unaware of any courses teaching Mercury as an introduction to
> logic programming, so I would be interested in seeing how it worked.
> My feeling is that it would work a lot better with students who have
> already studied a strongly typed functional language, as far less time
> would have to be spent explaining the type system.  Mercury would also
> have the strong advantage that the lecturer wouldn't have to point out
> all the problems with the non-logical features of Prolog, as seems to
> happen frequently in our lectures.
>
Does this mean that there has never been such a course before?

@Kathryn: At Melbourne university, has there ever been any thought or 
even trial to teach Mercury that way? This is a very exciting question 
to me.

@ Jon: If you say with Philip Wadler Java is a 'functional language' - 
then our students certainly have studied one... ;-) (Ok, Java is a 
little more bureaucratic...)

Of course, a typeless language is a rather unfamiliar thing to our 
students (unless they do web scripting), as they come from Java (and 
C#). To my personal impression, the compiler is really quite verbose, 
and -- again -- programming in interpreted mode is not familiar to our 
students.

Ralph Beckett recently gave me notice that type class are quite 
'complete' now (what I could partially verify), what appears to me as a 
great progress for integrating the architectural concepts so popular in 
OO like design patterns - what I want to say is Mercury can be 
programmed in a whole lot of styles logic, functional, OO with only 
having to learn ONE programming environment.

Putting in question 'di' and 'uo' irritates me deeply: Aren't they the 
very heart of Mercury (see 'Strong modes can change the world'...)? This 
is the same as putting in question 'private' in OO, isnt't it? Lately, I 
began to deal with the extended modes and finding no real doc, I did it 
by guessing - it was kinda fun to see it is possible to work with )o+> 
this way... What I mean is, if you like, you can go programming with 
very low discipline (even without a sophisticated IDE), what is good for 
starting projects and mediocre motivated students...


I wish you all a great weekend,

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