Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004933OCamlOCaml generalpublic2009-12-03 17:092010-06-07 10:28
Reportertill 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version3.12.0+dev 
Summary0004933: Functor drop private type information
Descriptionmodule type Priv = sig
  type t = private int
end

module Make (Unit:sig end): Priv = struct type t = int end

module A : Priv = Make (struct end)
Additional InformationThis seems linked to: 4816
TagsNo tags attached.
Attached Files

- Relationships
related to 0004816closedgarrigue module abbreviations remove 'private' type restrictions 

-  Notes
(0005185)
garrigue (manager)
2009-12-07 13:30

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.
(0005186)
garrigue (manager)
2009-12-07 14:07

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...
(0005546)
garrigue (manager)
2010-06-07 10:28

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.

- Issue History
Date Modified Username Field Change
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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker