Foo.hs-boot:3:1: Type constructor ‘Foo’ has conflicting definitions in the module and its hs-boot file Main module: type role Foo phantom data Foo a Boot file: data Foo a
Trac metadata
Trac field
Value
Version
7.8.2
Type
Bug
TypeOfFailure
OtherFailure
Priority
normal
Resolution
Unresolved
Component
Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
If I add a role annotation to the hs-boot file, this works.
My guess is that since the hs-boot doesn't have the information about the data constructors, it cannot infer the phantom role of the parameter.
Still, I wish I didn't have to deal with this. But if this isn't possible, at least the error message should suggest adding the role annotation to the hs-boot file.
If I add a role annotation to the hs-boot file, this works
Yes, that's the solution.
.
My guess is that since the hs-boot doesn't have the information about the data constructors, it cannot infer the phantom role of the parameter.
Yes. As documented here, in the last bullet point before 4.7.10, role inference in hs-boot files defaults to representational, the most common case.
Still, I wish I didn't have to deal with this. But if this isn't possible, at least the error message should suggest adding the role annotation to the hs-boot file.
Yes, absolutely. I will fix in due course, and clarify some of this in the manual as well.
In the following example the complete data declaration happens to be present in the hs-boot file:
Foo.hs:
module Foo whereimport Bardata P a = P
Foo.hs-boot:
module Foo wheredata P a = P
Bar.hs:
module Bar whereimport {-# SOURCE #-} Foo
Could you now do role inference in the hs-boot file as well, so that the example compiles? My use-case is that I generate hs-boot files by copying whole declarations. Thank you.
Yes, the suggestion in ticket:9204#comment:95987 is reasonable: Use phantom as the default role in hs-boot files when the definition is supplied. Even today, GHC does do role inference in hs-boot files -- it just uses a different default. But there is no reason to change the default if a definition is supplied.
Thanks for the suggestion.
However, because this is a user-facing change, it's not appropriate (in my opinion) to make the change for 7.10. And, it's just barely possible that this will break code. The following compiles today:
A.hs-boot:
module A wheredata P a = P
A.hs:
module A wheretype role P representationaldata P a = P
Under the proposed change, this example would fail due to the missing role annotation in the hs-boot file. That said, I'm still in favor of the change, just documenting what would break.