Re: Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4)

Tom Ellis <[email protected]>
Newsgroups gmane.comp.lang.haskell.cafe
Message-ID <ZhUx627xEunNOXVg@cloudinit-builder>
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/Core/ParseTree.hs
> 
> 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 <
> [email protected]>:
> > 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_fields.html#extension-DuplicateRecordFields
> >
> > 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.