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

Recursive modules don't normalize type aliases correctly #7699

Closed
vicuna opened this issue Dec 24, 2017 · 3 comments
Closed

Recursive modules don't normalize type aliases correctly #7699

vicuna opened this issue Dec 24, 2017 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Dec 24, 2017

Original bug ID: 7699
Reporter: ubsan
Status: resolved (set by @xavierleroy on 2018-01-12T13:01:08Z)
Resolution: not fixable
Priority: normal
Severity: minor
Version: 4.06.0
Category: typing

Bug description

Given two recursive modules T1 and T2, and an opaque type T1.t which is equal to b, references to T1.t in T2 are not normalized to have type b in T1.

Steps to reproduce

module rec Foo : sig
  val make: Bar.t
end = struct
  let make = Bar.make
end and Bar : sig
  type t
  val make: t
end = struct
  type t = unit
  let make = ()
  let _: unit = Foo.make
end

gives the error:

File "./test.ml", line 11, characters 16-24:
Error: This expression has type Bar.t but an expression was expected of type
unit

Additional information

One can get around this issue by not using type aliases - I've gotten around this in my own code with a single-variant variant type.

@vicuna
Copy link
Author

vicuna commented Dec 24, 2017

Comment author: @lpw25

This is a well-known issue with recursive modules called the "double-vision" problem. There are some recursive module systems that avoid it -- see various works by Dreyer and Rossberg -- but changing OCaml's module system to match one of those would be a significant piece of work, so don't expect this to be fixed any time soon.

@vicuna
Copy link
Author

vicuna commented Dec 24, 2017

Comment author: ubsan

dang :(

Well, I guess it can be closed then? Or maybe it should become a docs bug

@vicuna
Copy link
Author

vicuna commented Jan 12, 2018

Comment author: @xavierleroy

In this particular case you can also export "Bar.t" transparently:

and Bar : sig type t = unit ... end = ...

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

1 participant