-
Notifications
You must be signed in to change notification settings - Fork 100
Fix resolution involving deeply nested substitutions #727
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
module type S = sig | ||
module M: sig | ||
type t | ||
end | ||
type t = M.t | ||
end | ||
module type T = S with type M.t := int | ||
|
Original file line number | Diff line number | Diff line change | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,46 @@ | ||||||||||||
Test to check that when doing a deep substitution inside a signature, | ||||||||||||
that items that reference that element are still correctly resolved | ||||||||||||
even if they're in a different path. | ||||||||||||
|
||||||||||||
$ cat m.mli | ||||||||||||
module type S = sig | ||||||||||||
module M: sig | ||||||||||||
type t | ||||||||||||
end | ||||||||||||
type t = M.t | ||||||||||||
end | ||||||||||||
module type T = S with type M.t := int | ||||||||||||
|
||||||||||||
|
||||||||||||
In this, we want to check that the type `t` in module type `T` has | ||||||||||||
its RHS correctly replaced with an `int` | ||||||||||||
|
||||||||||||
$ ocamlc -c -bin-annot m.mli | ||||||||||||
$ odoc compile m.cmti | ||||||||||||
$ odoc link m.odoc | ||||||||||||
$ odoc html-generate m.odocl --indent -o . | ||||||||||||
Comment on lines
+18
to
+21
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have a helper script for this:
Suggested change
The output is slightly different because it sets the parent. If that's annoying, perhaps we can change the script and update every other tests ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do have a helper script, true - but this way the test is a bit more self contained, and I often find this useful when I'm working on them because I find building them out of tree to be essential when developing (and debugging) these tests. |
||||||||||||
$ odoc_print m.odocl -r T.t | ||||||||||||
{ | ||||||||||||
"id": { | ||||||||||||
"`Type": [ | ||||||||||||
{ "`ModuleType": [ { "`Root": [ "None", "M" ] }, "T" ] }, | ||||||||||||
"t" | ||||||||||||
] | ||||||||||||
}, | ||||||||||||
"doc": [], | ||||||||||||
"equation": { | ||||||||||||
"params": [], | ||||||||||||
"private_": "false", | ||||||||||||
"manifest": { | ||||||||||||
"Some": { | ||||||||||||
"Constr": [ | ||||||||||||
{ "`Resolved": { "`Identifier": { "`CoreType": "int" } } }, | ||||||||||||
[] | ||||||||||||
] | ||||||||||||
} | ||||||||||||
}, | ||||||||||||
"constraints": [] | ||||||||||||
}, | ||||||||||||
"representation": "None" | ||||||||||||
} | ||||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not render nested substitutions ? It is rendered for
T
:but the documentation for
T
doesn't mention any substitution at all:Showing the substitution is not that bad:
It would be even more useful in case of non-destructive substitution because the definition of
t
would be in the same documentation page:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it was certainly not my intention to remove the 'with type' always, just the construct
sig ... end with type ...
I'll double check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I misinterpreted what you mean - though I'm still not quite sure! To be clear, we've got:
You wrote that you thought this would be better:
I don't think you mean
M.S
- I think you might have meantS.M
- but we can't do this because we can't have paths to elements within module types. Is this correct?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By
M.S
, I meantS.M
or evenTest.S.M
, sorry for the confusion.sig ... end with type ...
is turned into justsig ... end
but I'd expectTest.S.M with type ...
even ifM
is not a module type.On the definition of
T
, we have the path toS
and the substitution, why can't nested substitution be represented the same way ?Perhaps we can represent it like
(module type of Test.S.M) with type ...
internally ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem isn't
M
, it'sS
-S
is a module type so we can't doS.M
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wouldn't be valid OCaml but it would be a valid reference (so can work internally). Do we require that every rendered paths should be valid OCaml paths ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even internally it's a Path not a Reference, and in any case I strongly prefer sticking to valid OCaml than to deviate. If the language supports it some day we can do it - for example I'm keeping an eye on the transparent ascription PR as that will help with some tricker parts of handling
module type of
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright :) Sorry for the digression.