> > On 26/04/16 09:20, AntC wrote: > > There's an intriguing comment here wrt anonymous records: ... > > I'm afraid the sentence on the wiki page is slightly misleading, ... > with the change to functional dependencies, > the overlapping instances solution works rather nicely, > in that it works if the field labels are distinct > and reports an error if not [1].
Thanks Adam, we're very much thinking along the same lines. Yes that's exactly where I am at. I too like the error message re overlapping instances. Contrast that for an HList style solution, you get instance match on the leftmost/outermost appearance of the label. So to detect duplicates you need a `Lacks` superclass constraint on the HList's tail. And to get `Lacks` to work, you need to create an instance; for which you then need an impossible-to-fulfill superclass constraint. Even with the best of documentation, you get a dense error message, quite possibly pointing to the wrong place. So unlike HLists, Nikita's Record<n>s are 'flat' (same as if you used plain tuples) and the instance matcher can look at all elements at the same time. Furthermore (closed) type families suffer a similar difficulty. The instance equations are ordered, so will pick the leftmost (or rightmost) appearance without complaint. To detect ambiguous getFields you need first a guard equation HasField n1 (Record2 n1 v1 n1 v2) = error: overlap For a two-tuple that's OK. For more than two you need guard equations for all of the ambiguous perms and combs. For a 24-tuple that's horrendous. For tuple extension or joining your head explodes. Even if we could automate generating the ambig instances somehow, it just feels wrong to get an instance/equation match when what you want is an error. > > I have been vacillating between type families and fundeps for the ORF > classes. I hadn't fully appreciated this point about overlap, but I > think it is a reason to prefer fundeps, which is the direction in which > I'm leaning. I'd be grateful for feedback on this issue though! > Yes, this seems a 'featurette' of Overlaps/FunDeps compared to closed type families. Should I regard it as a 'happy accident' that might stop working some day? It does seem a pretty fundamental requirement for Overlaps -- providing of course IncoherentInstances is never switched on in some distant module. > > In general, to avoid overlapping instances, one trick is to introduce a > closed type family that discriminates between the parameters, > along with an auxiliary class whose instances match > on the result of the type family. ... Thanks. Yes I'm aware of that approach from HList. It works a little more nicely with type families. The difficulty remains that as soon as you want overlaps in such a way that takes you to FunDeps, it's very difficult to 'mix modes' with type families. AntC > > [1] https://gist.github.com/adamgundry/7292df8cef62fd6750885be3f5f892e7 > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users