Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4)
Hi all, I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4. Using the new version, I get errors like ~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields` I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated! Thanks for reading Cheers, Han Joosten
Hello Han, Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.) At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie... Tom On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Hi Tom, The code can be found here: https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/... The idea is that I have several data definitions each with a field named `pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken: data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields } class Traced a where origin :: a -> Origin instance Traced Foo where origin = pos instance Traced Bar where origin = pos Of course I could rewrite the instance definitions something like instance Traced Foo where origin (Foo{pos = p} = p but that looks ugly, and it feels strange. Thanks for replying Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
Hello Han,
Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.)
At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie...
Tom
On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
I see, thanks. So it does look like my wild guess was correct. GHC will no longer disambiguate ambiguous field selectors. Perhaps you're supposed to use OverloadedRecordDot for this (I'm not sure, I don't use it myself). Tom On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote:
The code can be found here: https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/...
The idea is that I have several data definitions each with a field named `pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken:
data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields }
class Traced a where origin :: a -> Origin
instance Traced Foo where origin = pos
instance Traced Bar where origin = pos
Of course I could rewrite the instance definitions something like
instance Traced Foo where origin (Foo{pos = p} = p
Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.)
At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie...
On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
By the way, how are you compiling this? I tried $ cabal build -w ghc-9.6 on branch upgrade-ghc but I get a cabal resolver error. Tom On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote:
I see, thanks. So it does look like my wild guess was correct. GHC will no longer disambiguate ambiguous field selectors. Perhaps you're supposed to use OverloadedRecordDot for this (I'm not sure, I don't use it myself).
On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote:
The code can be found here: https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/...
The idea is that I have several data definitions each with a field named `pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken:
data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields }
class Traced a where origin :: a -> Origin
instance Traced Foo where origin = pos
instance Traced Bar where origin = pos
Of course I could rewrite the instance definitions something like
instance Traced Foo where origin (Foo{pos = p} = p
Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.)
At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie...
On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
I figured out to go for the easy way, not to figure out all the (fancy?) language pragma's. I will just rewrite the broken bits. Not hard to do, mostly annoying and less concise. I use stack to build. That way I know exactly the versions that will be used for each and every dependency. Thanks for helping out! Han. Op di 9 apr 2024 om 15:01 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
By the way, how are you compiling this? I tried
$ cabal build -w ghc-9.6
on branch upgrade-ghc but I get a cabal resolver error.
Tom
On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote:
I see, thanks. So it does look like my wild guess was correct. GHC will no longer disambiguate ambiguous field selectors. Perhaps you're supposed to use OverloadedRecordDot for this (I'm not sure, I don't use it myself).
On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote:
The code can be found here:
https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/...
The idea is that I have several data definitions each with a field
named
`pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken:
data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields }
class Traced a where origin :: a -> Origin
instance Traced Foo where origin = pos
instance Traced Bar where origin = pos
Of course I could rewrite the instance definitions something like
instance Traced Foo where origin (Foo{pos = p} = p
Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.)
At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie...
On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to
ghc
9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5
or the field ‘pos’ of record ‘PPurpose’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5
or the field ‘pos’ of record ‘P_ViewSegment’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5
or the field ‘pos’ of record ‘P_ViewD’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5
or the field ‘pos’ of record ‘P_IdentDf’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5
or the field ‘pos’ of record ‘P_BoxItem’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9
or the field ‘pos’ of record ‘TemplateKeyValue’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5
or the field ‘pos’ of record ‘BoxHeader’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5
or the field ‘pos’ of record ‘P_SubIfc’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9
or the field ‘pos’ of record ‘P_Interface’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5
or the field ‘pos’ of record ‘P_Population’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9
or the field ‘pos’ of record ‘P_Rule’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5
or the field ‘pos’ of record ‘PairViewSegment’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9
or the field ‘pos’ of record ‘P_NamedRel’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5
or the field ‘pos’ of record ‘PAtomPair’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5
or the field ‘pos’ of record ‘Pragma’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5
or the field ‘pos’ of record ‘P_Relation’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5
or the field ‘pos’ of record ‘Representation’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5
or the field ‘pos’ of record ‘PConceptDef’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5
or the field ‘pos’ of record ‘P_Pattern’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5
or the field ‘pos’ of record ‘Role’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5
or the field ‘pos’ of record ‘P_RoleRule’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5
or the field ‘pos’ of record ‘P_Enforce’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5
or the field ‘pos’ of record ‘MetaData’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each
have a
field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Perhaps this trick may help you? https://discourse.haskell.org/t/how-to-do-user-facing-records-in-2024/9176/2... On Wed, Apr 10, 2024 at 08:43:08AM +0200, Han Joosten wrote:
I figured out to go for the easy way, not to figure out all the (fancy?) language pragma's. I will just rewrite the broken bits. Not hard to do, mostly annoying and less concise. I use stack to build. That way I know exactly the versions that will be used for each and every dependency.
Thanks for helping out! Han.
Op di 9 apr 2024 om 15:01 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
By the way, how are you compiling this? I tried
$ cabal build -w ghc-9.6
on branch upgrade-ghc but I get a cabal resolver error.
Tom
On Tue, Apr 09, 2024 at 01:17:47PM +0100, Tom Ellis wrote:
I see, thanks. So it does look like my wild guess was correct. GHC will no longer disambiguate ambiguous field selectors. Perhaps you're supposed to use OverloadedRecordDot for this (I'm not sure, I don't use it myself).
On Tue, Apr 09, 2024 at 01:57:48PM +0200, Han Joosten wrote:
The code can be found here:
https://github.com/AmpersandTarski/Ampersand/blob/upgrade-ghc/src/Ampersand/...
The idea is that I have several data definitions each with a field
named
`pos`. I have a class that conveniently gets that field from whatever instance. This used to work, but now is broken:
data Foo = Foo { pos :: !Origin, ... other fields } data Bar = Bar { pos :: !Origin, ... other fields }
class Traced a where origin :: a -> Origin
instance Traced Foo where origin = pos
instance Traced Bar where origin = pos
Of course I could rewrite the instance definitions something like
instance Traced Foo where origin (Foo{pos = p} = p
Op di 9 apr 2024 om 12:38 schreef Tom Ellis < tom-lists-haskell-cafe-2023@jaguarpaw.co.uk>:
Would it be possible to produce a minimal example that demonstrates the problem? Or at the very least share the code? It's very hard to know where to start diagnosing. (Although perhaps someone else knows without having to see code.)
At a wild guess, have you been hit by this?
As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated.
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/duplicate_record_fie...
On Tue, Apr 09, 2024 at 12:18:14PM +0200, Han Joosten wrote:
Hi all,
I am currently migrating a Haskell project that uses ghc 8.10.7 to
ghc
9.6.4.
Using the new version, I get errors like
~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5
or the field ‘pos’ of record ‘PPurpose’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5
or the field ‘pos’ of record ‘P_ViewSegment’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5
or the field ‘pos’ of record ‘P_ViewD’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5
or the field ‘pos’ of record ‘P_IdentDf’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5
or the field ‘pos’ of record ‘P_BoxItem’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9
or the field ‘pos’ of record ‘TemplateKeyValue’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5
or the field ‘pos’ of record ‘BoxHeader’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5
or the field ‘pos’ of record ‘P_SubIfc’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9
or the field ‘pos’ of record ‘P_Interface’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5
or the field ‘pos’ of record ‘P_Population’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9
or the field ‘pos’ of record ‘P_Rule’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5
or the field ‘pos’ of record ‘PairViewSegment’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9
or the field ‘pos’ of record ‘P_NamedRel’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5
or the field ‘pos’ of record ‘PAtomPair’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5
or the field ‘pos’ of record ‘Pragma’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5
or the field ‘pos’ of record ‘P_Relation’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5
or the field ‘pos’ of record ‘Representation’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5
or the field ‘pos’ of record ‘PConceptDef’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5
or the field ‘pos’ of record ‘P_Pattern’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5
or the field ‘pos’ of record ‘Role’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5
or the field ‘pos’ of record ‘P_RoleRule’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5
or the field ‘pos’ of record ‘P_Enforce’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5
or the field ‘pos’ of record ‘MetaData’, defined at
/workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5
Previously, it was totally fine to have different data types each
have a
field with the same name, as long as you used `DuplicateRecordFields`
I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated!
Thanks for reading Cheers, Han Joosten
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (2)
-
Han Joosten -
Tom Ellis