Re: [Caml-list] teaching OCaml

[John Whitington <john@coherentgraphics.co.uk>]

Hi Bob,

robert.muller2@gmail.com wrote:
> Greetings. Bob Muller here, in the CS dept. at Boston College. I've set out to
> develop an intro CS course in ML that I hope will be well-suited for similar
> universities in the US. My original plan was to teach the course in SML but
> after talking with a few people at neighboring schools, I switched to OCaml. I
> am now in the final weeks of the first run of the course.  I plan to document
> my experience more fully at some point but I wanted to touch base with the
> OCaml community because I'm teaching the course again in the spring and I am
> leaning toward switching to F#.
>
> While OCaml has in many respects been great and it's easy to see that my
> students find the OCaml style of coding very compelling, there are significant
> problems. Of course, OCaml wasn't designed for teaching but I'm hoping that
> someone on this list might be able to advise me about solutions to some of
> these that I just don't know about.
>
> 1. Error messages: It's difficult to give good type errors for ML but I was
> hoping that the state-of-the-art of type error reporting had improved. When my
> students receive a type error, they are utterly mystified,

Arthur Chargueraud has done some work on this, by fixing up the error 
messages using an auxilliary typechecker. There is an OPAM compiler 
switch for it, I recall.

http://gallium.inria.fr/blog/making-it-easier-for-beginners-to-learn-ocaml/

I think it's very important for students to understand how to do a kind 
of mock type inference on paper or in their head. This helps a lot with 
understanding errors, though they will always happen, and the error 
messages are tough to begin with. For example, from the standard library:

let rec fold_left f accu l =
   match l with
     [] -> accu
   | a::l -> fold_left f (f accu a) l

1. Looking at the form of the first line, the type must have the form

... -> ... -> ... -> ...

2. Looking at lines 2 and 3, we know that l is a list, and that the 
final output has the same type as the 'accu' (assign it 'a):

... -> 'a -> ... list -> 'a

3. Look at the last line. Now we can see that f is a function, because 
it is applied, and we can see its first argument is the same type as 
'accu' too:

('a -> ... -> ...) -> 'a -> ... list -> 'a

Since 'accu' feeds back through the recursive call, 'f accu a' must have 
that  type too:

('a -> ... -> 'a) -> 'a -> ... list -> 'a

We have no information to show that the type of the list which 'a' comes 
from in 'f accu a' must be the same as 'a, so call it 'b:

('a -> 'b -> 'a) -> 'a -> 'b list -> a

If they can do that one, they can probably do most things that might 
appear in a beginners course.

I'm also strongly opposed to beginners being encouraged to use type 
annotations in code, which people sometimes do to get 'better' error 
messages. I think it confuses more than helps. But that seems to be a 
controversial opinion, from what I can tell.

> 2. GUIs: several of my problem sets work with simple graphics (e.g., rendering
> tessellations) or animations (e.g., a maze walk or a simplified form of
> tetris, or the game "Flow"). We have been hobbling along with the Graphics and
> Labltk modules for this but it has been more pain than my students ought to
> know. We also have some problem sets that work with audio so I would like
> support for that.

I wrote a version of Graphics which writes to PDF. If you have a PDF 
reader which re-renders when the file on disk is updated, this can be 
used for the non-interactive stuff, and it feels a bit more modern than 
the built-in graphics window.

https://github.com/johnwhitington/graphicspdf

You can get it in OPAM.

Thanks,

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/