|Anonymous | Login | Signup for a new account||2017-02-26 04:38 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004933||OCaml||-OCaml general||public||2009-12-03 17:09||2010-06-07 10:28|
|Status||closed||Resolution||no change required|
|Target Version||Fixed in Version||3.12.0+dev|
|Summary||0004933: Functor drop private type information|
|Description||module type Priv = sig|
type t = private int
module Make (Unit:sig end): Priv = struct type t = int end
module A : Priv = Make (struct end)
|Additional Information||This seems linked to: 4816|
|Tags||No tags attached.|
Actually this is not directly related to 4816 (but I leave the relation anyway, as a reminder)
The problem is just that both for private rows and private abbreviations, strengthening is not monotonous.
Namely, when you define
module A = Make(B)
it actually gets the signature
module A : sig type t = Make(B).t end
Now, if B is not a real module, this is not a valid signature, so the type-checker tries to see if
transform Make(B).t into a valid type. Unfortunately, for private types there is no valid alternative,
so the abbreviation is just discarded, and you get
module A : sig type t end
To avoid this problem you just have to pass a proper module as argument to your functor:
module B = struct end
module A = Make(B)
I still wonder whether it would not be possible to extract the private type information from the
context in this case.
Actually, this works with private rows, but the type printed was wrong in that case.
I fixed that in Ctype.nondep_type_decl.
It should also be possible to support the private abbreviation case, by using try_expand_once_opt,
and reinstating the private flag. But this is a bit dangerous...
Finally fixed this for private abbreviations too, in revision 10532.
The idea is not to strengthen types when the path is not a valid one.
Unfortunately this seems to solve only a limited number of problems.
|2009-12-03 17:09||till||New Issue|
|2009-12-04 19:14||xleroy||Relationship added||related to 0004816|
|2009-12-07 11:46||xleroy||Status||new => assigned|
|2009-12-07 11:46||xleroy||Assigned To||=> xleroy|
|2009-12-07 11:46||xleroy||Assigned To||xleroy => garrigue|
|2009-12-07 13:30||garrigue||Note Added: 0005185|
|2009-12-07 13:30||garrigue||Status||assigned => resolved|
|2009-12-07 13:30||garrigue||Resolution||open => no change required|
|2009-12-07 14:07||garrigue||Note Added: 0005186|
|2010-04-30 06:34||garrigue||Status||resolved => assigned|
|2010-06-07 10:28||garrigue||Note Added: 0005546|
|2010-06-07 10:28||garrigue||Status||assigned => closed|
|2010-06-07 10:28||garrigue||Fixed in Version||=> 3.12.0+dev|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|Copyright © 2000 - 2011 MantisBT Group|