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
[module type of] does not produce type equalities for representation types #5241
Comments
Comment author: @garrigue IIRC, this is actually the intended behavior. |
Comment author: lealanko What additional safety does hiding the type equality provide? If the interface defined a polymorphic variant instead of a variant, then the type in an including interface would be equal to the original, and I don't think anyone would consider this a problem. I am using [include M] to wholly re-export M from a larger module, and I'd like to indicate this in the interface with [include module type of M]. If I have to add equality constraints for all the exported type representations, maintenance becomes more of a hassle as the including module has to track the evolution of the types in M. |
Comment author: @garrigue OK, I should have noted that there are two distinct problems. A last solution would be to have two "module type of", one with the current semantics, and another adding the equations from the beginning. But I have no idea for the syntax... |
Comment author: lealanko The reimplementation use case indeed requires that abstract types are kept abstract. Still, to me, [module type of M] very much gives the impression that it is the signature of the module M, not just some abstract signature that M happens to implement. I suspect that very often if we want to reimplement a module Foo, we actually want to implement the signature defined in foo.mli. So here is a feature suggestion that would be even more generally useful: Let every interface file foo.mli define a module type Foo in the global module type scope. If we also have foo.ml, then we just have Foo : Foo. This should be no problem since modules and module types have different namespaces. Then, if we want to reimplement that interface as MyFoo : Foo, we just write a myFoo.mli whose body is "include Foo". So [Foo] would be the signature defined in foo.mli, with the types just as abstract or transparent as they are defined in that file, and [module type of Foo] would be the signature of the particular module Foo, with all the type equalities that this implies. This would be useful also because at times it would be convenient to have a lone foo.mli define a global name for a signature Foo, even if there is no foo.ml. |
Comment author: @damiendoligez So this is really a feature request (and a big one): that .mli files bind module type names like .ml files bind module names. |
Comment author: lealanko Certainly not! That was simply an offhand suggestion regarding how to best accommodate the "reimplement existing module" use case. The actual problem I am reporting is that because [module type of] currently tries to accommodate this use case, it does not expand to the module type inferred for the module expression, while the documentation claims it does. |
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. |
@lpw25 Do you still intent to change this ? |
I do. I have written the patch to make So, the change is essentially blocked on having transparent module ascription. |
Fair enough. :) |
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 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. |
Original bug ID: 5241
Reporter: lealanko
Status: acknowledged (set by @damiendoligez on 2011-05-16T14:48:05Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.13.0+dev
Category: typing
Monitored by: yziquel dario till "Julien Signoles"
Bug description
The manual says:
"The construction module type of module-expr expands to the module type (signature or functor type) inferred for the module expression module-expr."
Hence, I would expect [module N = M] to be equivalent to [module N : module type of M = M]. However, this is not true:
Because of the lacking type equality, [N.a] is now distinct from [M.a]. This causes a bit of headache. There is a workaround:
This does not yet work in 3.13 since r10669 apparently hasn't yet been merged to trunk. But still, I don't think this should be needed. [module type of] should give the most specific signature of a module, and for types with representations, that should include a type equation.
The text was updated successfully, but these errors were encountered: