Which brings us back to fclabels I suppose.Can you elaborate this? I haven’t fully understand what is “incorporate the tag in the class from the start” . Thanks you.
This creates a conflict if you use an (Int,Int) tuple because there are either no definitions or two conflicting definitions for get.class Has a t whereget :: t -> a
instance Has a (a, b) whereget (a, _) = a
instance Has b (a, b) whereget (_, b) = b
Has (Tagged “GetGetsFirst” a) (a,b)All I'm saying is that it seems useful or even necessary for sanity to combine Has and Tagged so that you can write
Has “fst” a (a,b)The implementation should be something simple like
class (KnownSymbol label) => Has label part whole | whole,label -> part whereget :: Proxy label -> whole -> part
-- 'Proxy label' is necessary because 'whole' and 'part' alone are not sufficient to determine the label. See (Int,Int).
I can see a potential problem because you can't hide instances. Once you define a Has-relationship, you can't cheaply change it. That could lead to conflicts, unless you hack around it with orphaned instances in a separate module. But you say you want to solve conflicts with tagging – so it would be reasonable to incorporate the tag in the class from the start. Which brings us back to fclabels I suppose.Does this differ significantly from fclabels or the upcoming OverloadedRecordFields extension? (Aside from being purely type driven, which has problems in your example if you compose a second Int into it.)1. Yes, it’s similar to OverloadedRecordFields but doesn’t force you to use a label, and you may use Tagged to label a field if you want.2. Yes, but again, you can use Tagged to allow same type in different disguise.