Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004816OCamlOCaml generalpublic2009-06-07 18:372011-05-29 12:14
Reporterjjb 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version3.11.1+dev 
Summary0004816: module abbreviations remove 'private' type restrictions
DescriptionConsider the following code:

    module M : sig
      type t = private T of int
      val mk : int -> t
    end = struct
      type t = T of int
      let mk x = T(x)
    end

    module M' = M

    let x = M'.mk 42

    let y = M'.T(42)

With 3.10.2, the let binding for y fails to type-check:

            Objective Caml version 3.10.2
    [snip]
    # let y = M'.T(42);;
    Characters 8-16:
      let y = M'.T(42);;
              ^^^^^^^^
    Cannot create values of the private type M'.t

With 3.11.1+rc1, however, it type-checks:

            Objective Caml version 3.11.1+rc1
    [snip]
    # let y = M'.T(42);;
    val y : M'.t = M'.T 42
    #

David Allsopp reports the same behavior on 3.11.0.
TagsNo tags attached.
Attached Files

- Relationships
related to 0004933closedgarrigue Functor drop private type information 

-  Notes
(0004987)
garrigue (manager)
2009-06-08 04:37

Fixed in CVS for 3.11.1.
A previous fix for private abbreviations had broken the behaviour for private types...
(0004994)
jjb (reporter)
2009-06-13 00:04

I am still seeing different behavior with 3.11.1 regarding the typing of
private types. Consider the following code:

    module M : sig
      type t = private T of int
      val mk : int -> t
    end = struct
      type t = T of int
      let mk x = T(x)
    end

    module M1 : sig
      type t = M.t
      val mk : int -> t
    end = struct
      type t = M.t
      let mk = M.mk
    end

    module M2 : sig
      type t = M.t
      val mk : int -> t
    end = struct
      include M
    end

    module M3 : sig
      type t = M.t
      val mk : int -> t
    end = M

With 3.10.2 this type-checks, but with 3.11.1, M1 type-checks but M2 and M3
fail:

Error: Signature mismatch:
       Modules do not match:
         sig type t = M.t = private T of int val mk : int -> t end
       is not included in
         sig type t = M.t val mk : int -> t end
       Type declarations do not match:
         type t = M.t = private T of int
       is not included in
         type t = M.t

Note that M1, M2, and M3 have identical meanings.
(0004995)
garrigue (manager)
2009-06-13 12:31

Actually the second bug your report has a different cause.
Namely the case when the implementation type was a private concrete type,
and the interface type a public abbreviation referring to this type,
was incorrectly refused. The problem was in file includecore.ml.

This is fixed in CVS, branch 3.11, but too late for 3.11.1.
(0004996)
garrigue (manager)
2009-06-14 10:01

Question to the original reporter:

It seems that ocaml-3.11.1 shipped with a partial fix, sound (i.e. private types are really private), but not complete (some correct re-exportations are refused by the compiler). So some correct software that compiled with 3.11.0 will not compile with 3.11.1. How bad is it for you? Do you know of any published software where such a problem occurs?
Since 3.11.0 was no sound, there may be also programs that took advantage of the unsoundness, but then refusing them is certainly correct.

- Issue History
Date Modified Username Field Change
2009-06-07 18:37 jjb New Issue
2009-06-08 04:37 garrigue Note Added: 0004987
2009-06-08 04:37 garrigue Status new => closed
2009-06-08 04:37 garrigue Resolution open => fixed
2009-06-08 04:37 garrigue Fixed in Version => 3.11.1+dev
2009-06-13 00:04 jjb Note Added: 0004994
2009-06-13 00:04 jjb Status closed => feedback
2009-06-13 00:04 jjb Resolution fixed => reopened
2009-06-13 12:31 garrigue Note Added: 0004995
2009-06-13 12:31 garrigue Status feedback => resolved
2009-06-13 12:31 garrigue Resolution reopened => fixed
2009-06-13 12:31 garrigue Assigned To => garrigue
2009-06-14 10:01 garrigue Note Added: 0004996
2009-12-04 19:14 xleroy Relationship added related to 0004933
2011-05-29 12:14 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker