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

Bad interaction between subtyping and recursive modules #4850

Closed
vicuna opened this issue Aug 24, 2009 · 2 comments
Closed

Bad interaction between subtyping and recursive modules #4850

vicuna opened this issue Aug 24, 2009 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Aug 24, 2009

Original bug ID: 4850
Reporter: @alainfrisch
Status: acknowledged (set by @xavierleroy on 2012-08-06T16:25:08Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.1
Target version: later
Category: typing
Tags: recmod
Monitored by: @jberdine "Julien Signoles"

Bug description

The following code is accepted by the type-checker:

module X: sig
type 'a t
val f: int t -> unit t
end = struct
type 'a t = {x: int}
let f x = (x : int t :> unit t)
end

If one turns it into a recursive module, the type-checkers complains with:

Error: Type int t = int X.t is not a subtype of unit t = unit X.t

The problem comes from:

  1. Ctype.subtype_rec expands abbreviations of type constructors with arity > 0.
  2. The typing of recursive modules introduces extra type manifests to type declarations (cf "anchor" in Typemod).

I guess the problem could occur with explicit type manifest as well, but in that case the user is in control of it. I'm unsure about the correct behavior of subtyping w.r.t. type abbreviation, but I'd clearly prefer it if turning a non-recursive module definition into a recursive did not not break type-checking.

Does restricting expansion to cases where the manifest is explicitly given by the programmer seem reasonable?

@vicuna
Copy link
Author

vicuna commented Aug 6, 2012

Comment author: @xavierleroy

I've been sleeping on these PR for too long, and still have no idea how to address them. Unassigning them from myself.

@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