Home * The Schemer Books

The slow-witted OCamler                                   Introduction


Article explains stuff from 'The little MLer' in ordinary prose.
Uses OCaml for examples.  Readers can suggest improvements.

Dear reader,

near the end of 2010 I read Felleisen and Friedman's 'The little MLer'
to learn functional programming in general and OCaml in particular.
Looking back I must say that I could have had it much easier with
another book.  To be honest I had to read it twice to make sense of it
and on some occasions it made me feel dumb, in fact so much so, that
on the second reading I summarized the whole book, just to make sure I
understood every important detail and not to go astray.  I called the
resulting notes 'The slow-witted OCamler' for no other reason than to
remind myself of the Kafkaesque intellectual experience I had gone

Let me emphasize that it was also a rewarding experience.  Not because
I eventually defeated the book.  Rather because the book didn't defeat
me, which is different.  But I also noticed while working through the
book and gathering information from other sources to tackle it, that I
was only scratching on a surface through which the authors wouldn't
let me see.  In other words, while many things are obvious and quite
easy to understand, sometimes they throw a piece of code at you
without bothering to explain its theoretical background and practical
purpose.  Well, at present I can make assumptions about these things
but not much more.

Yes, I've seen the references at the end of the book, but at this
point I don't feel like reading through five tomes about mathematical
logic, category theory and automatic proof just yet.  I'd be more
interested in simple and practical applications of some constructs
presented in the book.  That's one reason why I dumped my notes here.
First of all because there are a few open questions concerning things
ranging from more trivial and less important things like OCaml syntax
to the problems I just mentioned, e.g. the thing in ch 7: Is that a
monad?  Is it used for lazy evaluation?  Does anybody use it and why?

Below the TOC you find some pointers that lead directly to questions
you could look at and help me finding answers.  The TOC points to the
sections of my notes, each corresponding to a chapter of the book.
The first chapters are easy and the notes are short.  The latter
chapters are difficult and the notes are more verbose.  If you think
you are also in need for a Kafkaesque experience, I urge you to read
through the whole set of notes and then point out things I didn't
understand, propose changes or additional information I could
integrate, or suggest how I could make the text more useful for

Although these pages are static, the content is kind of interactive.
Just send oldfashioned email to d at d12k dot org.


Less interesting:

Chapter 1:
  Types, variants, parametrized types, recursive types,
  polymorphic types.
Chapter 2, Chapter 3:
  Recursive functions, pattern matching.
Chapter 4, Chapter 5:
  Tuples, lists.

More interesting:

Chapter 6:
  Trees, symbolic expressions, mutual reference, mutual recursion.
Chapter 7:
  Functions' types, higher-order functions, monads(?).
Chapter 8:
  Functional abstraction, type inference and type variables,
  currying and recursion, intension vs. extension of functions.
Chapter 9:
Chapter 10:


1: Can I match several constructors of a type
   with one pattern and extract a nested value?

2: When pattern matching, why shouldn't I
   compact several values to be matched
   when they are not adjacent in their

3: Does type 'chain' define a monad?

4: Are monads used to implement lazy

5: Regarding the intensional approximation
   of extensionally equivalent but
   intensionally different functions.

6: Your thoughts on the last example
   in ch. 8.

7: Unqualified alias for qualified names?

8: Explicit signature and structure
   definitions in separate files?

ds, 20110614.