Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: 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: Wolfgang Lux <lux@h...>
Subject: Re: Some questions about the module system...

> [stuff deleted]
> > module MakePQueue(O: ORDER)(Leq: sig val leq : O.t -> O.t -> bool end): PQUEUE ->
> >   struct
> >     ...
> >   end
>    
> > and then you can apply this functor as follows:
> > 
> > module DepthFirstPQueue =
> >   MakePQueue(Node : NODE with t = node)(struct let leq = Node.less_depth end)
> > 
> > module BestFirstPQueue =
> >   MakePQueue(Node : NODE with t = node)(struct let leq = Node.less_dist end)
> 
> Thank you, I was so brain-fuddled with trying to work my way around the *other*
> side of the problem that I couldn't think properly. Yours is a handy solution.
> 
> However, don't you think such ad hoc procedures beat the whole purpose of
> neatness of code, separability, etc.? I remember having to pass around a 
> reference to a parsing function to do something pretty wild to the original CAML
> parser-generating construct, and this thing with the modules smacks strongly of it!
>  

Youe are right. The above solution was really an ad-hoc one. It suits
the problem as you described it, but it may well get ugly for more
complex problems. Generally I would prefer a solution along the lines
of the other solution I presented.

> > You might even write down a functor to convert your NODE module
> > together with its ordering function into an ORDER module:
> > 
> > module OrderOfNode(Node : NODE)(Leq : sig value leq : O.t -> O.t -> bool end) : ORDER =
> >   struct
> >     type t = Node.node
> >     let format = Node.format
> >     let leq = Leq.leq
> >   end
> 
> Yes, I have thought about doing this thing, for other purposes, but for this particular
> one it would mean actually discarding the rest of the ADT of the nodes, and who
> knows what you may need in a future implementation of the NODEs.
> 
> However, maybe it wasn't a bad idea after all, if you recommend it as well.

You could take this solution even further and make all information
including the above functor OrderOfNode local to your Node module, e.g.:

module type NODE =
  sig
    type node
    module type LEQ
    module DepthFirstLeq : LEQ
    module BestFirstLeq : LEQ
    module AsOrder(Leq : LEQ): ORDER
    ...
  end

module Node =
  struct
    type node = ...
    ...
    module type LEQ = sig value leq : node -> node -> bool end
    module DepthFirstLeq = struct let leq = less_depth end
    module BestFirstLeq = struct let leq = less_dist end
    module OrderOfNode(Leq : LEQ): ORDER =
      struct
        type t = node
        let format = format
	and leq = Leq.leq
      end
    ...
  end

> 
> Nevertheless, I would still like to know if someone had answers for the original
> questions,
> 
> b) what are the reasons not to allow module values aliasing to view modules under
> different signatures? Is it envisioned for the future at all?
> 

As I am no one of the designers of OCaml I can't answer the
question. But actually I must admit that I do not miss that
feature. Actually I can even live without type sharings at all. T
think type sharings are an ad-hoc feature which had to be introduced
into the SML module systems because of its limitations. But with the
presence of higher order functors in OCaml together with their
applicative semantics I have yet not found a case where it had to use
type or module. IMHO using functors instead of sharing constraints
also makes the dependencies between modules clearer.

Regards
Wolfgang

----
Wolfgang Lux
WZH Heidelberg, IBM Germany             Internet: lux@heidelbg.ibm.com
+49-6221-59-4546                        VNET:     LUX at HEIDELBG
+49-6221-59-3500 (fax)	                EARN:     LUX at DHDIBMIP