caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: "Sébastien Furic" <sebastien.furic@lmsintl.com>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] Questions about default instances
Date: Mon, 8 Aug 2011 16:14:51 +0900	[thread overview]
Message-ID: <20B7E892-BB5F-40CE-9428-512E94B2B5A3@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <4E3AC747.2010405@lmsintl.com>

On 2011/08/05, at 1:22, Sébastien Furic wrote:

> What is the usual way in OCaml to define mutually recursive classes that share default instances?

There is no concept of "default instance" in OCaml, and as you discovered yourself,
default instances create problems with initialization.
Namely, an object constructor might attempt to access a default instance before it is built,
so we need a way to know whether it is ready or not.
This is not specific to OCaml.
But since OCaml has no null pointers (with good reasons!), the only way to know whether
a value is ready or not is to use either an option or a a lazy value.

So a first solution to your problem is (using immediate objects):

class type object_ = object
 method to_string: string
end

class type boolean = object
 inherit object_
 method not_: boolean
 method or_: boolean Lazy.t -> boolean
 method and_: boolean Lazy.t -> boolean
 method if_: 'a . 'a Lazy.t -> 'a Lazy.t -> 'a
end

let rec lazy_false = lazy (object (self : #boolean)
 method to_string = "false"
 method not_ = Lazy.force lazy_true
 method or_ chk = Lazy.force chk
 method and_ _ = self
 method if_ _ chk = Lazy.force chk
end)

and lazy_true = lazy (object (self : #boolean)
 method to_string = "true"
 method not_ = Lazy.force lazy_false
 method or_ _ = self
 method and_ chk = Lazy.force chk
 method if_ chk _ = Lazy.force chk
end)

let false_ = Lazy.force lazy_false
and true_ = Lazy.force lazy_true

Note that I used class types rather than virtual classes, since there is no point
in a virtual class having no concrete methods.
If you want a virtual class later, you can even build it from the class type:

class virtual boolean_class = object (self : #boolean)
  method as_bool = self#if_ (lazy true) (lazy false)
end

Now, if you want to use classes instead of immediate objects, there is an additional problem:
a class can only recurse with other classes.
A simple way out is to use recursive modules.

module rec Bool : sig
  class false_class : boolean
  class true_class : boolean
  val true_ : boolean Lazy.t
  val false_ : boolean Lazy.t
end = struct
  class false_class = object (self : #boolean)
    method to_string = "false"
    method not_ = Lazy.force Bool.true_
    method or_ chk = Lazy.force chk
    method and_ _ = (self :> boolean)
    method if_ _ chk = Lazy.force chk
  end

  and true_class = object (self : #boolean)
    method to_string = "true"
    method not_ = Lazy.force Bool.false_
    method or_ _ = (self :> boolean)
    method and_ chk = Lazy.force chk
    method if_ chk _ = Lazy.force chk
  end

  (* Default instances (that I would have preferred to inject
     directly in definitions above) *)
  let false_ = lazy (new false_class)
  and true_ = lazy (new true_class)
end

Recursive modules do not remove the need for laziness:
for exactly the same reason, all recursion must go through
a module containing only functions and lazy values.

Jacques Garrigue


> In order to illustrate my problem, let's suppose we would like to define a hierarchy of classes defining booleans /à la/ Smalltalk:
> 
> -8<-------------------------------------------------------------
> 
> class virtual object_ = object
>  method virtual to_string: string
> end
> 
> class virtual boolean = object
>  inherit object_
>  method virtual not_: boolean
>  method virtual or_: boolean Lazy.t -> boolean
>  method virtual and_: boolean Lazy.t -> boolean
>  method virtual if_: 'a . 'a Lazy.t -> 'a Lazy.t -> 'a
> end
> 
> class false_class = object (self)
>  inherit boolean
>  method to_string = "false"
>  method not_ = new true_class
>  method or_ chk = Lazy.force chk
>  method and_ _ = (self :> boolean)
>  method if_ _ chk = Lazy.force chk
> end
> 
> and true_class = object (self)
>  inherit boolean
>  method to_string = "true"
>  method not_ = new false_class
>  method or_ _ = (self :> boolean)
>  method and_ chk = Lazy.force chk
>  method if_ chk _ = Lazy.force chk
> end
> 
> (* Default instances (that I would have preferred to inject
>   directly in definitions above) *)
> let false_ = new false_class
> and true_ = new true_class
> -8<-------------------------------------------------------------
> 
> Methods corresponding to message not_ in both false_class and true_class should ideally return a instance of, respectively, true_class and false_class that would have been created once and for all (instead of a fresh instance each time they are invoked). How does one achieve this in OCaml the functional way? (i.e., without resorting to references, but also, ideally, without resorting to lazy values)
> The use of immediate objects is IMO a better choice to implement booleans (because I don't want nor need to let users subclass false_class and true_class). Here is an attempt:
> 
> -8<-------------------------------------------------------------
> (* Using the same definition of boolean above *)
> let rec false_ = object (self)
>  inherit boolean
>  method to_string = "false"
>  method not_ = true_
>  method or_ chk = Lazy.force chk
>  method and_ _ = self
>  method if_ _ chk = Lazy.force chk
> end
> 
> and true_ = object (self)
>  inherit boolean
>  method to_string = "true"
>  method not_ = false_
>  method or_ _ = self
>  method and_ chk = Lazy.force chk
>  method if_ chk _ = Lazy.force chk
> end
> -8<-------------------------------------------------------------
> 
> I get “Error: This kind of expression is not allowed as right-hand side of `let rec'”. I wonder why OCaml does not accept the definition of recursive values like above (notice that references to false_ and true_ are “protected” by method definitions). Wouldn't it be safe to extend recursive definitions with this pattern?
> 
> Cheers,
> 
> Sébastien.
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



  reply	other threads:[~2011-08-08  7:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 16:22 Sébastien Furic
2011-08-08  7:14 ` Jacques Garrigue [this message]
2011-08-16  8:42   ` Sébastien Furic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20B7E892-BB5F-40CE-9428-512E94B2B5A3@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=sebastien.furic@lmsintl.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).