Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006528OCamltypingpublic2014-08-30 01:012017-03-14 08:37
Assigned Togarrigue 
PlatformOSOS Version
Product Version4.01.0 
Target VersionlaterFixed in Version 
Summary0006528: type constraints alter signatures in unusual ways
DescriptionI'm not sure exactly what to call this (or if this is in fact a bug) but the following two compilation errors surprised me and seem related: In the first, a value is annotated as having a type exactly as it appears in the signature. That type-checks, but the module still fails to compile.

$ rlwrap ocaml
        OCaml version 4.01.0

# module M : sig
    type 'a t constraint 'a = [< `Foo of _]
    val create : 'a -> 'a t
    end = struct
    type 'a t = 'a constraint 'a = [< `Foo of _]
    let create : 'a. 'a -> 'a t = fun x -> x
Error: Signature mismatch:
       Values do not match:
         val create : ([< `Foo of 'b ] as 'a) -> 'a t
       is not included in
         val create : ([< `Foo of 'b & 'c ] as 'a) -> 'a t

In the second, you are not allowed to replace one type constraints with the same type and the same constraints:

$ rlwrap ocaml
        OCaml version 4.01.0

# module type S = sig type 'a t constraint 'a = [< `Foo of _] end;;
module type S = sig type 'a t constraint 'a = [< `Foo of 'b ] end
# module type S' = sig include S include S with type 'a t := 'a t end;;
Error: In this `with' constraint, the new definition of t
       does not match its original definition in the constrained signature:
       Type declarations do not match:
         type 'a t = 'a t constraint 'a = [< `Foo of 'b & 'c & 'd ]
       is not included in
         type 'a t constraint 'a = [< `Foo of 'b ]
       Their constraints differ.

(Obviously, in that example, in real life it wouldn't be the same signature twice but two different signatures still having the same constraint on their type.)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
lpw25 (developer)
2015-05-11 23:07
edited on: 2015-05-11 23:08

Reminder sent to: garrigue

@garrigue Could you take a look at this? In particular, should it be postponed until after 4.02.2?

garrigue (manager)
2015-05-11 23:46

Unification on types with only an upper bound can be tricky.
I suppose the way to fix it is to handle polymorphic variant types in type definitions the way they are handle in pattern matching, but this means some large changes, so delay this at least until 4.03.
garrigue (manager)
2017-03-14 08:37

Proving the equality for these types would require a new algorithm detecting that these types are actually equivalent because the type variables do not appear anywhere else in the types.
Worse, the general case would require finding in the whole type that two type variables are undistinguishable.
So this is not an implementation problem: one first has to come around with a proved algorithm to do that...
For this reason we can only say that such constraints (where the type variable is not bound elsewhere) are unsupported.

- Issue History
Date Modified Username Field Change
2014-08-30 01:01 mkoconnor New Issue
2014-09-15 15:22 doligez Status new => acknowledged
2014-09-15 15:22 doligez Target Version => 4.02.2+dev / +rc1
2015-05-11 23:07 lpw25 Note Added: 0013898
2015-05-11 23:08 lpw25 Note Edited: 0013898 View Revisions
2015-05-11 23:46 garrigue Note Added: 0013899
2015-05-11 23:47 garrigue Target Version 4.02.2+dev / +rc1 => 4.03.0+dev / +beta1
2016-04-06 13:50 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2017-02-16 14:01 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-03-14 08:37 garrigue Note Added: 0017639
2017-03-14 08:37 garrigue Assigned To => garrigue
2017-03-14 08:37 garrigue Severity minor => feature
2017-03-14 08:37 garrigue Target Version undecided => later

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker