Version française
Home     About     Download     Resources     Contact us    
Browse thread
Some questions about the module system...
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Francisco J. Valverde <fva@i...>
Subject: Some questions about the module system...

Hello mailing list,

here are some questions I would like to pose the system implementors
concerning the module system in O'Caml. The mail is quite lengthy, and I
apologise in case somebody else has asked the same... (I have been unable to
look up the question in the mailing archives).

1) is there any reason (unclear semantics, scope-holing, etc.) why the O'Caml
module system won't allow an "include <signature>" feature? I keep bumping
into it when I try to write module hyerarchies (or adapt ML code from texts ;) ).
What I am asking about is a nice "feature" for doing:

module type ELEMENT =
  sig
     type t
     val format : t -> unit
  end;;

module type ORDER =
sig
   include ELEMENT
   val leq : t -> t -> bool
end;;

module type DOMAIN =
sig
   include ORDER
   val bottom: t
end;;

(...and so on and so forth), instead of writing "all that code again".

b) My second question concerns module coercion by means of module signatures.
Sharing constraints between module types is really necessary for code
abstraction, but I found "value aliasing" really useful as well (I don't
know the exact term for the feature so I will describe it).

Suppose you have this priority queue functor requesting an ORDER on values of
the type shown above:

module MakePQueue = (struct ... end: (O: ORDER) -> PQUEUE);;

and a module implementing NODEs in a graph with data about the distance from
the node to a "root" and an accumulated value describing another distance
measure:

module NODE =
sig
  type node ={ depth: int; dist: int; ...}
  ..
end;;

Now, I would like to implement 2 different searching strategies namely
DepthFirst and heuristic search ( "A" strategy someone would say), for
which I need to consider two different orders (take my word for it):

value less_depth: node -> node -> bool	(* depthFirst order *)
value less_dist: node -> node -> bool	(* A* search order *)

How could I view NODE as these two different orders so that MakePQueue doesn't
complain? Answer: *alias* any of the orders to the order defined in ORDER:

(* this won't work in O'Caml 1.01 *)
module DepthFirstPQueue =
  MakePQueue (Node: NODE with t = node (* and val leq = less_depth *));;

module BestFirstPQueue =
  MakePQueue (Node: NODE with t = node (* and val leq = less_dist *));;

Unless I got it wrong all you can do for now is write TWO module signatures, say
NODE1 and NODE2, in which you define the required order with the adequate name,
that is to say "leq". *You* have to keep consistency between the rest of the primitives
on your own, and this is really... burdensome!

My feeling is that implementing this amounts to *rewriting* "leq" as
"less_dist", but this is merely a sintactic procedure and I am not sure
how would the semantics be affected: are modules just "environments" as
in ML, or do we have a more comvoluted semantica which rules out  this
behaviour?

I would like any comments about this, or other (more imaginative) ways
around these *burdensome* ways of writing code...

Francisco J. Valverde-Albacete
'Area de Tecnolog'ia Electr'onica
Dept. de Ingenier'ia (Area de Teconolog'ia Electr'onica)
Univ. Carlos III de Madrid
ESPAÑA (Spain)