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
Broken toplevel printing for types and modules (rec/nonrec not shown correctly) #7453
Comments
Comment author: @diml I had a look at this. I wrote two small functions to check if a type/module is recursive and select the rec_status field in the implementation of "show_XXX" according to this. The branch is here: https://github.com/diml/ocaml/tree/fix-toplevel-type-and-module-printing It seems to work, there is just a bug when calling #show_module multiple times that I haven't fixed yet. Another approach would be to record the recursive status inside the type/module declaration, so that the output of #show matches what the user wrote. Currently you get nonrec if the type is not in fact recursive:
|
Comment author: @yallop Thanks for looking at this. I don't think that preserving what the user wrote is especially worthwhile; the important thing is that what is printed is as close to correct as possible. If it's not too difficult, I think the best scheme would be:
For actually-recursive types there's no difference between your current scheme and the proposal above. And there's no difference for types that actually need 'nonrec', either. The only difference is for non-recursive types that can be written equivalently either with or without 'nonrec', such as 'type t = int', and it's best if those are printed as simply as possible. |
Comment author: voglerr Is there something blocking this?
Sounds perfect. |
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. |
The code in the problem report now works in
But printing types defined using
|
I added a known-bug test for these faulty (non)use of One slightly strange behavior of the test, unrelated to the present discussion (it is not with # module M : sig end = struct end;;
module M : sig end
# module rec M : sig type t = Loop of M.t end = struct type t = Loop of M.t end;;
module rec M : sig type t = Loop of M/2.t end |
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. |
This is not quite fixed yet: @gasche's |
All examples are fixed by #10416 (and this time without fatal errors when type t;;
type u = [ `U of t]
type t = A of [ u | `V ] | B of s
and s = C of t;;
#show t;; ) and recursive modules. |
Thank you, @Octachron! |
Original bug ID: 7453
Reporter: @yallop
Assigned to: @diml
Status: assigned (set by @diml on 2017-01-13T17:39:51Z)
Resolution: open
Priority: normal
Severity: minor
Category: toplevel
Monitored by: @gasche @hcarty
Bug description
Recursive type definitions are incorrectly displayed as explicitly non-recursive definitions:
And recursive module definitions are incorrectly displayed as implicitly non-recursive definitions:
The text was updated successfully, but these errors were encountered: