You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 778 Reporter: administrator Status: closed (set by @xavierleroy on 2013-08-31T10:44:10Z) Resolution: suspended Priority: normal Severity: feature Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Dan Arnon
Version: 3.02
OS: Linux
Submission from: 63.120.156.243 (63.120.156.243)
I defined the following module type:
module type X =
sig
type t
module Y:
sig
type t
end
with type t = t
end
The type constraint at the end of the type of module Y looks cyclic, but it
shouldn't be: it basically means
that the type t of Y should be the same as the type t of X. The compiler seems
to understand that and it compiles this without any complaint. However, the .mli
file that it creates looks a bit different:
module type X =
sig
type t
module Y :
sig
type t = t
end
end
This is just another way to express the same constraint. So far so good.
However, when I try to compile the .mli file, I get the following error:
"The type abbreviation t is cyclic"
There is a problem here somewhere: if the compiler accepted my type definition,
and then converted it to what it considered to be an equivalent type definition,
then it should accept its own definition as well and compile it without any
complaint. If it wants to complain, it must complain about my original
definition already. If in fact the two definitions are not equivalent for some
reason, then the compiler should not convert one to the other.
The text was updated successfully, but these errors were encountered:
The type constraint at the end of the type of module Y looks cyclic, but it
shouldn't be: it basically means
that the type t of Y should be the same as the type t of X. The compiler
seems
to understand that and it compiles this without any complaint. However, the
.mli
file that it creates looks a bit different:
module type X =
sig
type t
module Y :
sig
type t = t
end
end
This is just another way to express the same constraint. So far so good.
No: this one is cyclic. The only proper way to describe your type is probably
your original definition. But it would be really messy to have the
pretty-printer do that, so you will have to correct the .mli by hand until
somebody finds a better way.
A simple workaround is either to use another name for your type, or to put the
first ocurrence in another submodule.
i.e.
module type X = sig
module T : sig type t end
module Y : sig type t = T.t end
end
module type X' = X with type T.t = int
Original bug ID: 778
Reporter: administrator
Status: closed (set by @xavierleroy on 2013-08-31T10:44:10Z)
Resolution: suspended
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Dan Arnon
Version: 3.02
OS: Linux
Submission from: 63.120.156.243 (63.120.156.243)
I defined the following module type:
module type X =
sig
type t
end
The type constraint at the end of the type of module Y looks cyclic, but it
shouldn't be: it basically means
that the type t of Y should be the same as the type t of X. The compiler seems
to understand that and it compiles this without any complaint. However, the .mli
file that it creates looks a bit different:
module type X =
sig
type t
module Y :
sig
type t = t
end
end
This is just another way to express the same constraint. So far so good.
However, when I try to compile the .mli file, I get the following error:
"The type abbreviation t is cyclic"
There is a problem here somewhere: if the compiler accepted my type definition,
and then converted it to what it considered to be an equivalent type definition,
then it should accept its own definition as well and compile it without any
complaint. If it wants to complain, it must complain about my original
definition already. If in fact the two definitions are not equivalent for some
reason, then the compiler should not convert one to the other.
The text was updated successfully, but these errors were encountered: