Browse thread
Instruction selection in the OCaml compiler: Modules or classes?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@u...> |
| Subject: | Re: [Caml-list] Instruction selection in the OCaml compiler:Modulesor classes? |
On Sat, 2007-02-24 at 15:58 +0100, Andreas Rossberg wrote: > "skaller" <skaller@users.sourceforge.net>: > > > > It seems like a module functor allows both anonymous > > signatures (structural) and also anonymous argument > > modules (structural), yet you cannot have > > anonymous functor applications: you have to bind the application to > > a module name. > > Not at all. For instance, given > > module Id(X : sig type t end) = X > module A = struct type t = int end > > it is perfectly legal to write: > > module A' = Id(Id(Id(A))) > > Obviosuly, the inner applications of Id are all "anonymous". > > Likewise, you can say > > (3 : Id(Id(A)).t) > > Also purely anonymous applications. I had no idea you could do that! > You can more or less do that already, as long as you introduce a suitable > global module to host the integer type: > > module Int = struct type t = int let compare = compare end > > signature A = sig ... val foo : u -> Set.Make(Int).t -> unit ... end > signature B = sig ... val bar : v -> w -> Set.Make(Int).t ... end > > Admittedly, the type looks a bit ugly, and it would be even nicer if Int was > in the stdlib. But that are merely a questions of library design. [..] > Due to the "weak syntactic notion of module equivalence" I was mentioning > earlier you have to make sure that all these type expressions really refer > to the same Int module. This is a limitation of OCaml's module type system, > and may be what sometimes gives the impression of "nominal" typing. Yes .. I think I see. Two such modules 'Int' would have the same type, but not the same 'identity'. In a similar way that module Int' = struct type t = int let compare = mycompare end has the same type as Int .. but it's a different module because the value of 'compare' member is different. I think what you're saying also explains some of the weird sharing constraints sometimes seen. [When I tried to implement modular functors in Felix I couldn't figure out what was going on and had to give up .. typeclasses were easier, but it's discouraging to find you can only have one total order defined for integers.. :] -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net