[Caml-list] About modules again

[Caml-list] About modules again

[Nicolas FRANCOIS]

I'd like to be able to define some polymorphic functions in module
signatures. I explain it right now : I have some abstract modules (this is
not my code, it seems to be a pre-project from Foc) :

module type Set =
sig
  type elem
    
  val (==) : elem -> elem -> bool     
      (* equality *)

  val normalize : elem -> elem      
      (* there may be more than one
	 representation of each element in the set,
	 this function may perform some simplification
      *)

  val print : elem -> unit          
      (* printing (using the Format library) *)
  val write : formatter -> elem -> unit    
      (* writing in file (using the Format library) *)
  val parse : char Stream.t -> elem
  val read : in_channel -> elem
      (* reading from file, compatible with write *)
  val write_bin : out_channel -> elem -> unit  
      (* writing as binary value *)
  val read_bin : in_channel -> elem         
      (* reading as binary value *)
end

module type Group =
sig
  include Set

  val zero : elem
    (* zero ! *)
  val (++) : elem -> elem -> elem         
      (* sum *)
  val (--) : elem -> elem -> elem         
      (* subtraction *)
  val opp : elem -> elem
      (* opposite (0 -- x) *)   
end

module type Ring =
sig
  include Group                         
    
  val one : elem                    
    (* one ! *)
  val t_of_int : int -> elem        
      (* the standard mapping from integer *)
  val ( ** ) : elem -> elem -> elem
      (* product *)
  val conjugate : elem -> elem
      (* conjugate value *)
end

So you see module type Ring implement the "methods" of Group. My problem
is : the exponentiation (x -> x^i for a positive integer) can be
accomplished with just the product, without knowledge of what the objects
are.

Next we define some Rings, filling the holes in the definitions :

module Ring_Z = 
  struct
    type elem = int
    type stathm = int
    let zero = 0
    let one = 1
    let t_of_int n = n
    let (++) = (+)
    let (--) = (-)
    let ( ** ) = ( * )
    let ( == ) = ( = )
    let opp x = - x
    let print = print_int
    let write ch = pp_print_int ch 
    let parse = parse_int
    let read ch = parse (Stream.of_channel ch)  
    let write_bin = output_value
    let read_bin = input_value
    let stathm = abs
    let less = (<)
    let (//) = (/)
    let (mod) = (mod)
    let div_mod x y = x / y, x mod y
    let normalize x = x
    let conjugate x = x
  end

(it's an Euclidian Ring, but that's not the point). So you see my problem
: I have to define a concrete method in an abstract module, just not to
have to fill the definition for every new Ring I define.

Is there a way to do this ? Or is this specific to objects ?

\bye

-- 

                   Nicolas FRANCOIS
            http://nicolas.francois.free.fr
 A TRUE Klingon programmer does NOT comment his code
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] About modules again

[Markus Mottl]

On Mon, 15 Jul 2002, Nicolas FRANCOIS wrote:
> (it's an Euclidian Ring, but that's not the point). So you see my problem
> : I have to define a concrete method in an abstract module, just not to
> have to fill the definition for every new Ring I define.
> 
> Is there a way to do this ? Or is this specific to objects ?

This is the point where higher-order modules (functors) enter the game.
If you have some common functionality that is shared across all rings,
you can factor it out in a functor body. E.g.:

  module MakeRing (Spec : RING_SPEC) : RING = struct
    include Spec

    (* All common stuff follows here *)
  end

Module "Spec" should adhere to a signature "RING_SPEC", the latter
specifying what is different or at least parameterizable for each
ring. Applying the functor to such a specification yields a module that
implements the signature RING, e.g.:

  module Ring_Z = MakeRing (Ring_Z_Spec)

The specification of rings over Z (Ring_Z_Spec) may itself be the result
of a functor application. This way you can highly modularize the creation
of algebraic structures.

Btw., you'd surely get into troubles using OO here. It is not very
suitable for such purposes, because it lacks expressiveness if you want
to specify interaction of several types (sorts) at an abstract level.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] About modules again

[Nicolas FRANCOIS]

Le Mon, 15 Jul 2002 10:44:35 +0200 Markus Mottl <markus@oefai.at> a écrit
:


> This is the point where higher-order modules (functors) enter the game.
> If you have some common functionality that is shared across all rings,
> you can factor it out in a functor body. E.g.:
> 
>   module MakeRing (Spec : RING_SPEC) : RING = struct
>     include Spec
> 
>     (* All common stuff follows here *)
>   end
> 
> Module "Spec" should adhere to a signature "RING_SPEC", the latter
> specifying what is different or at least parameterizable for each
> ring. Applying the functor to such a specification yields a module that
> implements the signature RING, e.g.:
> 
>   module Ring_Z = MakeRing (Ring_Z_Spec)
> 
> The specification of rings over Z (Ring_Z_Spec) may itself be the result
> of a functor application. This way you can highly modularize the
> creation of algebraic structures.

I see your point. Conway does something like this in his math packages.
I'll try to adapt the technique.

Thanks Markus.

\bye

-- 

                   Nicolas FRANCOIS
            http://nicolas.francois.free.fr
 A TRUE Klingon programmer does NOT comment his code
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners