From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.6.10/8.6.6) id SAA25631 for caml-redistribution; Fri, 10 May 1996 18:08:52 +0200
Received: from gr6.u-strasbg.fr (gr6.u-strasbg.fr [130.79.6.86]) by pauillac.inria.fr (8.6.10/8.6.6) with SMTP id OAA19299 for <caml-list@pauillac.inria.fr>; Fri, 10 May 1996 14:52:26 +0200
Received: by gr6.u-strasbg.fr (4.1/SMI-3.2-jjp/4/6/92)
	id AA06291; Fri, 10 May 96 14:57:11 +0200
Date: Fri, 10 May 96 14:57:11 +0200
From: boos@gr6.u-strasbg.fr (Christian Boos)
Message-Id: <9605101257.AA06291@gr6.u-strasbg.fr>
To: caml-list@pauillac.inria.fr
Cc: Thorsten Ohl <ohl@crunch.ikp.physik.th-darmstadt.de>
Subject: Re: Class variables in O'Caml??? + questions
In-Reply-To: <9605101046.AA12307@crunch>
References: <9605101046.AA12307@crunch>
Sender: weis



Hello, 

Thorsten Ohl writes:
 > (...)
 > 
 > The typical application is a class of non-uniform random number
 > generators, where the distribution to be generated would be an
 > instance variable, while the state of the underlying uniform
 > generator should be a class variable.  This way, differrent instances
 > will generate different distributions, but draw from the _same_ source
 > of random numbers.
 > 
 > It is possible to emulate this with references, of course.  But it
 > would be somewhat unnatural ...
 > 

I played with O'Caml too ...

IMO, the use of references is not so unnatural. Together with structs,
it provides  a clean way  to encapsulate global  state and actions for
classes.

I would illustrate this on a small example, a simple unique identifier
generator:

 #module Identifier :
 #  sig
 #    class identifier (unit) =
 #      val id : int
 #      val mutable nb_queries : int
 #      method id : int
 #      method nb : int
 #    end
 #  end =
 #  struct
 #    let state = ref 0
 #
 #    class identifier () = 
 #       val mutable nb_queries = 0
 #       val id = let s = !state in incr state; s
 #
 #       method id = nb_queries <- succ nb_queries; id
 #       method nb = nb_queries
 #     end
 # end 
 #;;
 module Identifier :
   sig
     class identifier (unit) =
       val id : int
       val mutable nb_queries : int
       method id : int
       method nb : int
   end
 end
 #


----

By the way, I've  perhaps discovered a bug, or  at least an unpleasant
feature:

It seems   that you  can't  hide the  internal    val's of your  class
definition, when exporting its signature.  What I expected is that the
previous example could be written:

 #module Identifier :
 #  sig
 #    class identifier (unit) =
 #      method id : int
 #      method nb : int
 #    end
 #  end = ...

thereby hiding completely  the way an identifier  is implemented.  But
the compiler isn't happy with that:

 Class types do not match:
   class identifier (unit) =
     val id : int
     val mutable nb_queries : int
     method id : int
     method nb : int
 end
 is not included in
 class identifier (unit) =
   method id : int
   method nb : int
 end


This is strange, since  in other situations,  type checking on classes
doesn't care of 'val's, as seen in the following example:

 #class a () = val a = 0 method get = a end;;
 class a (unit) =
   val a : int
   method get : int      (* val a : ... *)
 end
 #class b () = method get = 0 end;;
 class b (unit) =
   method get : int      (* no val *)
 end
 #new a () = new b ();;  (* but same type !! *)
 - : bool = false


But that's a minor point. 

Another  one  is that the  very   interesting contribution of  Jacques
Garrigue   and  Jun P.  Furuse  (labeled  and   optional  arguments to
functions) hasn't  merged with the   mainstream. Will this happen  one
day, at least optionaly (sort of -withlabels option) ?

Anyway, Caml is still going better and better ... That's great !


-----------------------------------------------------------------------------
- Christian Boos, 
- Etudiant en Thèse d'Informatique
- http://dpt-info.u-strasbg.fr/~boos/