OCaml: Objects (haifengl.wordpress.com)

Older, hopefully still relevant, article about OCaml objects : http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ (from 0install author)

I went in expecting to see a write up on Common Lisp's CLOS[1], because at a recent Clojure Meetup, the speaker put forth the claim that CLOS is the most powerful OO system out there. He didn't have time to validate the claim, but it may be of interest to those who like this article.

[1] http://cl-cookbook.sourceforge.net/clos-tutorial/index.html

Total agreement!

OCaml's object system is wonderfully austere. It arises as a pretty natural extension of the more restrained signature subtyping relation---and this helps drive home, as this article also emphasizes, the vital distinction between subclassing and subtyping. That alone means that you'll have a more well-principled and reasonable object system than basically any other one I've ever used.

In day-to-day OCaml, I often hear people suggest that one should avoid the object system. The primary things it buys you are access to the row-typing system and class/object constructor hierarchies. It however is a bit slower due to the use of dynamic dispatch (instead of compiling vtables statically to their use site) and can face some inference issues.

That said, row types are an incredibly useful type construct (often Haskellers lament the fact that they're missing leading to the creation of things like Ermine and Vinyl). Cautious use of the object system is very exciting!

OCaml objects are pretty neat, although I rarely ever end up using them. Although I also rarely ever use OCaml for that matter.

One issue with the article - the author confuses duck typing and structural typing. While they are similar, there are important differences. OCaml uses structural typing (which enforces type at compile time) and not duck typing.

This post is also a great demonstration as to why a programming language cannot be evaluated as a feature checklist.

OCaml's object system is certainly awesome but in practice you'll find it is unevenly used -- some never use it, while I'm sure there are others who use it heavily. Because it behaves in a way that is not quite compatible with the rest of the language it is inconvenient to mix APIs that use the two styles of programming. Another comment here on HN links to a post that summarizes with the rule of thumb of simply "don't use objects".

The lesson is that any given feature exists in an ecosystem of other features and its utility is dictated by many things (impedance mismatch with the rest of the language or even language cultural problems) other than the specification itself.

To me the post is really not making the case at all that OCaml's object system is "best", as suggested in the HN headline. Really the only comparison to any other system is contrasting row polymorphism to duck typing. Like another user I was actually expecting this to be about CLOS based on the title. It'd still be a hard claim to make given some of the warts CLOS has, but at least it's a claim that people will often genuinely make.

(This also seems to be the fourth time the same post was submitted by the same user, with increasingly clickbaity headlines.)

What I never understood is why OCaml allows row polymorphism in objects, but not in record types. For example, we can write:

  let bar x = x#info + 1

and OCaml will give a type:

  val bar : < info : int; .. > -> int = <fun>

which is precisely what we want since we can now define functions on any object that has an info member. At the same time, we can't write

  let buz x = x.info + 1

because we receive the error

  Error: Unbound record field info

This is a big deal since the exposed members of objects must be methods in OCaml. Certainly, we can declare values and mutable values, but these are not exposed in the objects type. Specifically,

  # class foo = object val info = 1 end;;
  class foo : object val info : int end
  # let bar = new foo;;
  val bar : foo = <obj>
  # bar#info;;
  Error: This expression has type foo
         It has no method info

In order to get around this, we can change these values to methods (or add getter methods that return these values). However, the problem with doing that is then we can't make a new object with all of the same values, but with the specified valued changed:

  # class foo = object method info = 1 end;;
  class foo : object method info : int end
  # let bar = new foo;;
  val bar : foo = <obj>
  # bar # info;;
  - : int = 1
  # let buz = bar with info = 2;;
  Error: Parse error: [str_item] or ";;" expected (in [top_phrase])

In other words, we don't have a good mechanism for creating a bunch of immutable objects.

In other words, OCaml records allow immutable records, but they lack row polymorphsim. OCaml classes allow row polymorphism, but disallow immutable updates (immutable updates meaning create a new object with everything the same, but one element different.)

Does anyone know why this is the case?

  (* Create a basic lens type *)
  type ('a, 'b) t = {
    get : 'a -> 'b;
    set : 'b -> 'a -> 'a
  }
  
  (* A base lens, kind of like a base class *)
  type 'a myrecord_lens = {
      foo : ('a,int) t;
      label : ('a,string) t
  }
  
  (* Record 1 *)
  type myrecord1 = {
      foo : int;
      bar : float;
      label : string
  }
  let myrecord1 = {
      foo = 1;
      bar = 2.3;
      label = "myrecord1"
  }
  let foo_lens = { 
      get = (fun x -> x.foo); 
      set = (fun v x -> { x with foo = v })
  }
  let bar_lens = { 
      get = (fun x -> x.bar); 
      set = (fun v x -> { x with bar = v })
  }
  let label_lens = { 
      get = (fun x -> x.label); 
      set = (fun v x -> { x with label = v })
  }
  let myrecord1_lens = {
      foo = foo_lens; 
      label = label_lens
  }
  
  (* Record 2 *)
  type myrecord2 = {
      foo : int;
      buz : string;
      label : string
  }
  let myrecord2 = {
      foo = 4;
      buz = "five";
      label = "myrecord2"
  }
  let foo_lens = { 
      get = (fun x -> x.foo); 
      set = (fun v x -> { x with foo = v })
  }
  let buz_lens = { 
      get = (fun x -> x.buz); 
      set = (fun v x -> { x with buz = v })
  }
  let label_lens = { 
      get = (fun x -> x.label); 
      set = (fun v x -> { x with label = v })
  }
  let myrecord2_lens = {
      foo = foo_lens; 
      label = label_lens
  }
  
  (* Write a generic function to work with these objects*)
  let myfunc (myrecord:'a) (lens:'a myrecord_lens) =
      let _ = Printf.printf "Working with: %s\n" (lens.label.get myrecord) in
      (lens.foo.get myrecord) + 1
  
  (* Get some results *)
  let _ = myfunc myrecord1 myrecord1_lens
  let _ = myfunc myrecord2 myrecord2_lens

  val myfunc : 'a -> 'a myrecord_lens -> int = <fun>
  Working with: myrecord1
  - : int = 2
  Working with: myrecord2
  - : int = 5

    type ('i, 'j) store = { get : 'j; set : 'j -> 'i };;

    let o = object
      val slot = 3
      method slot = 
        { get = slot
        ; set = fun slot' -> {< slot = slot' >}
        }
    end

    val o : < slot : ('a, int) store > as 'a

    # o#slot.get;;
    - : int = 3
    # (o#slot.set 10)#slot.get;;
    - : int = 10
    # o#slot.set o#slot.get;;
    - : < slot : ('a, int) store > as 'a = <obj>