Message-Id: <9607241032.AA127933@idse.heidelbg.ibm.com>
To: fva@ing.uc3m.es
Subject: Re: Some questions about the module system...
In-Reply-To: (Your message of Wed, 24 Jul 96 11:25:26 EST.)
<9607240936.AA07121@elrond.uc3m.es>
Date: Wed, 24 Jul 96 12:32:24 +0100
From: Wolfgang Lux <lux@heidelbg.ibm.com>
> [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