Type constraints
[
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:  20041207 (18:13) 
From:  William Lovas <wlovas@s...> 
Subject:  Re: [Camllist] Type constraints 
On Tue, Dec 07, 2004 at 06:44:36PM +0100, Damien Doligez wrote: > > On 7 Dec 2004, at 15:57, Andreas Rossberg wrote: > > >Is this really a counterexample? I don't see any problem with making > >it polymorphic  it evaluates to ref, and ref can happily be > >polymorphic. > > Yes, well I simplified it a bit too much. Try this instead: > > let module M = struct let v = ref [] end in M.v;; I'm still not convinced. Yes, the type variable should not be generalized in the above, by analogy with: # ref [];;  : '_a list ref = {contents = []} But the `let module' in question  or one similar in spirit, at least  # let module M = struct let v = fun x > x end in M.v;;  : '_a > '_a = <fun> is analogous to the expression # fun x > x  : 'a > 'a = <fun> in which the type variable *is* generalized. The following behavior confuses me, too: # let module M = struct let v = fun x > x end in (M.v 5, M.v true);;  : int * bool = (5, true) This expression has type bool but is here used with type int # let v = let module M = struct let v = fun x > x end in M.v in (v 5, v true);; ^^^^ This expression has type bool but is here used with type int Why is the type variable generalized inside the `let module's body but not generalized if we pass it to the outside? So the `ref' example above as a counterexample is at the very least hiding some of the story. What's really going on here? William