Re: Superclass Equality constraints cp FunDeps

On at Apr 29 05:55:14 UTC 2017, Anthony Clayden wrote: ... So should I reasonably have known that a superclass constraint with FunDeps on the superclass induces FunDeps on the sub-class without explicitly needing to declare so?
(I'm not complaining, more surprised/impressed.)
From experimenting, FunDeps seem to come through from a superclass of a superclass of a superclass of the class.
This from David Feuer says http://stackoverflow.com/questions/35252562/find-an-element-in-an-hlist/3526... "superclass context is critical .... GHC always commits to an instance before checking the instance constraints, but it doesn't even try to find an instance until after solving the superclass constraints. So we need to use the superclass constraint to fix ..." Presumably that's the mechanism that induces FunDeps from supeclass constraints. Is that behaviour officially documented somewhere? (I remember when Type Families and (~) Constraints were first released, they weren't available superclass. Then there were a couple of releases you could put superclass constraints, but they weren't effective.) AntC

On Apr 30, 2017, at 6:37 AM, Anthony Clayden
wrote: Is that behaviour officially documented somewhere?
Not that I can find. Documentation on functional dependencies is somewhat lacking. This may be because fundeps has received little love of late. Otherwise, I agree with your notes. Documentation patches are warmly accepted! Richard

On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg
On Apr 30, 2017, at 6:37 AM, Anthony Clayden < anthony_clayden@clear.net.nz> wrote: Is that behaviour officially documented somewhere?
Not that I can find. Documentation on functional dependencies is somewhat lacking. This may be because fundeps has received little love of late.
Not just fundeps; the originally cited behavior of equality constraints could also stand to be documented. In fact, I'd noticed a few shortcomings in equality constraint documentation --- including the question of, are they always enabled, or are there particular extensions that enable them? And if so, should they also have their own extension that becomes implied by those other extensions? So it's not even just documentation. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Documentation is just about always suboptimal -- but the best people to suggest concrete improvements are those who were confused to begin with. So, by all means, submit patches! Some relevant discussion on this point is on https://ghc.haskell.org/trac/ghc/ticket/10431 Currently, there is no extension for ~. It's enabled either by GADTs or TypeFamilies. I agree that this is not the best design, and the ticket above is a plan to fix it. Probably wouldn't take much more than someone with the will to make the changes! Richard
On Apr 30, 2017, at 3:35 PM, Brandon Allbery
wrote: On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg
mailto:rae@cs.brynmawr.edu> wrote: On Apr 30, 2017, at 6:37 AM, Anthony Clayden
mailto:anthony_clayden@clear.net.nz> wrote: Is that behaviour officially documented somewhere? Not that I can find. Documentation on functional dependencies is somewhat lacking. This may be because fundeps has received little love of late.
Not just fundeps; the originally cited behavior of equality constraints could also stand to be documented. In fact, I'd noticed a few shortcomings in equality constraint documentation --- including the question of, are they always enabled, or are there particular extensions that enable them? And if so, should they also have their own extension that becomes implied by those other extensions? So it's not even just documentation.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net http://sinenomine.net/
participants (3)
-
Anthony Clayden
-
Brandon Allbery
-
Richard Eisenberg