Re: Class variables in O'Caml??? + questions

Christian Boos (boos@gr6.u-strasbg.fr)
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
Subject: Re: Class variables in O'Caml??? + questions
In-Reply-To: <9605101046.AA12307@crunch>

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/