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 manifests do not support type variable substitutions #4907

Closed
vicuna opened this issue Nov 2, 2009 · 5 comments
Closed

Type manifests do not support type variable substitutions #4907

vicuna opened this issue Nov 2, 2009 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Nov 2, 2009

Original bug ID: 4907
Reporter: @mmottl
Assigned to: @garrigue
Status: assigned (set by @garrigue on 2012-06-01T07:32:44Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.11.1
Category: typing
Monitored by: "Julien Signoles" @hcarty @mmottl

Bug description

The following would seem like a perfectly legitimate thing to do:

type ('a, 'b) t = { a : 'a; b : 'b }
type ('a, 'b) u = ('a, 'b option) t = { a : 'a; b : 'b option }

Unfortunately, the compiler fails with:

File "foo.ml", line 3, characters 5-63:
Error: The variant or record definition does not match that of type
('a, 'b option) t

This does not quite seem correct.

This restriction makes it impossible to e.g. repeat a type definition in a more specialized way such that the preprocessor can exploit the extra syntactic representation to generate code more flexibly from the type definition.

@vicuna
Copy link
Author

vicuna commented Dec 9, 2009

Comment author: @damiendoligez

The problem is that a record type declaration is generative, so your second record type is
not an instance of the first. Can this be changed without major changes to the typechecker?
I don't know.

@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 18, 2020
@garrigue
Copy link
Contributor

Actually, I strongly prefer not changing the current behaviour.
If two nominal types are equal, their parameters should be equal too.
This has implications on the ability to unify their type constructors (generativity in Haskell parlance)..

@mmottl
Copy link
Contributor

mmottl commented May 18, 2020

Makes sense. This issue is really old, feel free to close it.

@garrigue
Copy link
Contributor

Thank you for your feedback.

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

3 participants