Class variables in O'Caml???

Class variables in O'Caml???

[Thorsten Ohl]

I have played a little bit with O'Caml yesterday and found that the
new features very conveniently formalize what I had been doing with
mutable records already.  Good job!

I have one question however: it seems that all variables in a class
are instance variables.  Have I overlooked something in the
documentation or can somebody explain to me why class variables
(i.e. variables that are shared mong all instances of a class) are a
bad idea?

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 ...

Cheers,
-Thorsten

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

[Christian Boos]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3171 bytes --]



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/                                 

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

[Thorsten Ohl]

>>>>> "Christian" == Christian Boos <boos@gr6.u-strasbg.fr> writes:

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

Sure, it us possible to do it.  But, IMHO, class variables should be
declared in the class and be opaque.  If you put several classes in a
module, the use of module wide references makes much less sense.
Another hack is to define a sub-module for each class, but that's not
nice either ...

I'm just curious if (and why) this syntactic sugar has been left out
intentionally.
-- 
Thorsten Ohl, Physics Department, TH Darmstadt --- PGP: AF 38 FF CE 03 8A 2E A7
http://crunch.ikp.physik.th-darmstadt.de/~ohl/ -------- 8F 2A C1 86 8C 06 32 6B

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

[Jerome Vouillon]

On Fri, 10 May 1996, Thorsten Ohl wrote:
> 
> >>>>> "Christian" == Christian Boos <boos@gr6.u-strasbg.fr> writes:
> 
> Christian> IMO, the use of references is not so unnatural. Together
> Christian> with structs, it provides a clean way to encapsulate global
> Christian> state and actions for classes.
> 
> Sure, it us possible to do it.  But, IMHO, class variables should be
> declared in the class and be opaque.  If you put several classes in a
> module, the use of module wide references makes much less sense.
> Another hack is to define a sub-module for each class, but that's not
> nice either ...
> 
> I'm just curious if (and why) this syntactic sugar has been left out
> intentionally.

It has not been left out intentionally. Many object-oriented languages 
(C++, Objective C and Modula 3, for instance) do not have class variables, 
so I did not even thought of adding them.
But I do not plan to implement class variables. I don't want to add too 
many features, and I don't think they are an important one: in my 
opinion, they are not commonly used, and they can be easily simulated 
using references as you noticed.

  Jerome Vouillon

Upcoming O'Labl

[Jacques GARRIGUE]

O'Caml comes, so what is happening to Label Special Light ?

Question 1 (Christian Boos <boos@gr6.u-strasbg.fr>)

 > 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) ?

No idea, I'm not the one who decides. But this may take some time, as
the following explains.

Question 2 (myself)

	 Will labeled arguments be ported to O'Caml ?

Yes, I'm working on it and have already an alpha version. Must be
checked carefully since the source changed a lot. I hope I can release 
it this week.

It is even more than labeled and optional arguments, since there are
also new polymorphic variants. This should mix nicely with objects.

However there are a number of problems, which will certainly not be
solved in the first release. That is, objects are breaking the basic
assumption of labels and comptionals compiling: that the actual type
of a function is known when it is applied. This is no longer true with 
methods. This means that there will be restrictions on the use of
labels in method definitions :-(, otherwise integration should go
smoothly.

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

True ! But I didn't think CSL would disappear so quickly !

	Jacques