Re: Imperative programming in Caml

[John Prevost <jmp@arsdigita.com>]

>>>>> "wt" == Walid Taha <taha@cs.chalmers.se> writes:

    wt> This is a great revision, and I particularly like the way that
    wt> you broke the task into smaller pieces.  The code is certainly
    wt> more structured.  However, you get the biggest payoff in your
    wt> rewrite from using the "option" type, and that is something
    wt> that I was trying to avoid (see "option types" below).

        {...}

    >> imperative call;
    >> let x = blah in
    >> imperative call
    >> 
    >> is much less disconcerting.

    wt> Not quite sure what you mean here.

If you write:

imperative call;
let x = blah in
  imperative call

then you get a little distracted by the indentation.  It's true that
the expression after a let ... in is part of that let, but since let
contains a single expression, keeping everything at the same
indentation level makes things a little more clear.  (That is, makes
it clear that you're doing one thing after another, whether it's the
imperative call or the binding call.)

    wt> Some of the choice was intentional.  In particular, "option"
    wt> types are very appropriate here, and were the first thing that
    wt> came to my mind when I was thinking about writing these little
    wt> examples.  But "option" types do, however, require introducing
    wt> the concept of parameteric polymorphism.  For my initial
    wt> postulate to be answer possitively, avoiding introducing
    wt> concepts from function programming would be necessary.

    >> The thing that distressed me most was trying to figure out what
    >> your ref ref was doing.  I understand it now.

    wt> I found the need for ref ref that strange too, but as you see,
    wt> for that "naive" imperative style, it is necessary.

Mmm.  I don't think you're going to have much success at showing that
O'Caml is a reasonable language without using at least some
polymorphism.  Perhaps this restatement of my previous code would
help, though:

type optional_int =
       | No_Int
       | Some_Int of int

module MutableIntList = struct
  type mcons = { mutable fore : optional_mcons;
                 mutable v    : int;
                 mutable back : optional_mcons }
   and optional_mcons =
         | No_Mcons
         | Some_MCons of mcons
  type mlist = { mutable head : optional_mcons;
                 mutable tail : optional_mcons }
...
end

type optional_bool =
       | No_Bool
       | Some_Bool of bool

type mutable_bool = { mutable v : bool }

...

This does everything that the previous code did, but with no
parametric polymorphism.  If polymorphism is difficult to explain, you
might show the example in this form, then point out how the same sort
of datastructure is used over and over again with no change but a
different name and different types inside.  Then you could introduce
option and ref types as a generalized solution.

John.