[mercury-users] Mercury needs a Tutorial

[Peter Schachte]

On Thu, Feb 11, 1999 at 09:57:11AM +0000, Ralph Becket wrote:
> Funnily enough, I started work on a tutorial last night.  A number of
> questions raise their heads:
> 
> 1. What level should we pitch the tutorial at?

I'd suggest pitching it at anyone with a bit of experience programming
in any langauge.  This, as I'm sure you realize, makes it difficult,
since Mercury is so different from conventional languages.  In fact,
given the size of the gap between conventional languages and Mercury,
the best approach to presenting it would probably *not* be to try to
build on experience with other languages.  Better, I think to present
it "from scratch," without much comparison to other languages.  This
may well yield a tutoral that would also be useful for someone with no
programming knowledge at all.

I remember my first undergraduate programming class used LISP.  The
professor asked at the beginning of the class who had some previous
programming experience.  I smugly raised my hand.  Then he said "you
people may have a harder time learning LISP than everyone else...."

> 2. To teach by example or not?

This is a harder question than it seems.  Some people (like me) really
need examples to learn.  Other people learn better from explanation.
Probably the best approach is to incorporate both, and let the user
decide which to read in which order.


>  I've started out with "Hello, World!"
> as is the tradition.

I don't think this is a good way to start.  I think it's better to
leave out as much as possible at the start, and work up to "Hello,
World!".  This may be heretical among Mercurians, but I think you
should avoid all declarations for the first examples, and add them as
you go along.  Make use of type, mode, and determinism inference!

You might proceed like:  start with arithmetic, just because it'll look
familiar and comfortable; then discuss database-y predicates; then
define a predicate in terms of other predicates; then cover recursion;
then hit types and type declarations; then pred declarations; then you
might as well cover func declarations and functions; then cover
instantiation and modes; then determinism; then uniqueness and mostly
uniqueness; then a quick mention of main/2.  That's probably enough to
get people going with Mercury.  It's quite a lot, isn't it?

I've found the family relationships example works pretty well to take
you from database-y predicates through recursion.  First you talk
about parent/2 and gender/2.  Then you define predicates like mother
and grandparent.  Then you cover ancestor and descendant.  Of course,
for Mercury, you'd probably want to use strings for people's names,
but using strings for genders is a bit clumsy, and this can be your
entre into types....

What would make it a lot easier to learn Mercury, I think, would be a
top level into which you can type queries, like Prolog has.  I
understand at the moment Mercury's read/3 can't read preds (closures),
so it wouldn't be easy to write one.  If the Mercury crew would add
this ability to read, writing a top level would probably not be too
hard and I think it would make an interactive style of tutorial
feasible.

> 3. Traditional `flat' text vs hypertext.

You might try SGML.  Check out http://www.sgmltools.org.  I haven't
used it myself, so I don't know whether it's ready for prime time, but
it looks easier to use than texinfo.  Otherwise texinfo is probably a
reasonable way to get both html and a typeset document.

> 4. One problem with teaching Mercury is that there are a number of
> subtle aspects to the language that you are usually forced to consider
> explicitly in your code (e.g. mode and determinism declarations).
> Teaching a non-Prolog type how "Hello, World!" works is non-trivial.
> The very first example introduces modules, interfaces, module use,
> implementations, unique modes and DCGs!  You should probably add the
> notion of `predicate' to that list as well.

Egads!  You should try to avoid teaching so much at once.

> 5. How far is the tutorial expected to take people?

The farther the better, but it'd probably be pretty easy to add to the
end of the tutorial, eg, to introduce type classes.  Then pasting
existential types to the end of that wouldn't be too hard, etc.

> This isn't going to work without feedback.  Are there people out there
> who can spare the odd ten minutes to look over what I've done and
> either recommend changes or improve it themselves?

Sure.  You'll probably get more (conflicting) advice than you'll know
what to do with.


-- 
Peter Schachte                     In a democratic time culture, everyone's
mailto:schachte at cs.mu.OZ.AU        time is valueable and no one's time is
http://www.cs.mu.oz.au/~schachte/  any more expendable than another's.
PGP: finger schachte at 128.250.37.3      -- Jeremy Rifkin