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 ... and ..." is not commutative #3601

Closed
vicuna opened this issue Apr 19, 2005 · 3 comments
Closed

"type ... and ..." is not commutative #3601

vicuna opened this issue Apr 19, 2005 · 3 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Apr 19, 2005

Original bug ID: 3601
Reporter: administrator
Assigned to: @garrigue
Status: closed (set by @garrigue on 2010-04-30T06:28:04Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 3.12.0+dev
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Francois Pottier
Version: 3.08+alpha1 (2004-07-03)
OS: RedHat Linux 8
Submission from: madiran.inria.fr (128.93.8.77)

Mutually recursive data type definitions, written using "type ... and ...",
are not commutative, even though one might expect them to be. This is
illustrated by the following two code snippets.

Snippet 1:

type t = { foo: t} and u = { foo: u };;

type t = { foo : t; }
and u = { foo : u; }

fun x -> x.foo;;

  • : t -> t =

Snippet 2:

type u = { foo: u } and t = { foo: t };;

type u = { foo : u; }
and t = { foo : t; }

fun x -> x.foo;;

  • : u -> u =

Suggested solution: detect that a record label is being defined twice
in this mutually recursive definition and reject the program. Do the
same for data constructors.

Note: this is not a theoretical example! I have actually written code
like this and got a type error much later in the program.

@vicuna
Copy link
Author

vicuna commented Apr 27, 2005

Comment author: administrator

The documentation doesn't say it's supposed to be commutative...

@vicuna
Copy link
Author

vicuna commented Apr 30, 2010

Comment author: @garrigue

Added a check for duplicates in revision 10331.
This is a hard error.
One might prefer a warning, but currently there is no way to use such duplicates.

@vicuna
Copy link
Author

vicuna commented Apr 30, 2010

Comment author: @garrigue

After some hesitation, I downgraded it to a warning, as programming style may change in the future.
(revision 10332)

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