Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type constraints alter signatures in unusual ways #6528

Closed
vicuna opened this issue Aug 29, 2014 · 5 comments
Closed

type constraints alter signatures in unusual ways #6528

vicuna opened this issue Aug 29, 2014 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Aug 29, 2014

Original bug ID: 6528
Reporter: mkoconnor
Assigned to: @garrigue
Status: acknowledged (set by @damiendoligez on 2014-09-15T13:22:18Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.01.0
Target version: later
Category: typing
Monitored by: @gasche @garrigue

Bug description

I'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
  end;;
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.)

@vicuna
Copy link
Author

vicuna commented May 11, 2015

Comment author: @lpw25

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

@vicuna
Copy link
Author

vicuna commented May 11, 2015

Comment author: @garrigue

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.

@vicuna
Copy link
Author

vicuna commented Mar 14, 2017

Comment author: @garrigue

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.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 11, 2020
@garrigue garrigue removed the Stale label May 11, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants