Quantcast

Superclass Equality constraints cp FunDeps

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Superclass Equality constraints cp FunDeps

AntC
The docos say [User Guide 10.14.1. on Equality Constraints]

> Equality constraints can also appear in class and instance
contexts.
> The former enable a simple translation of programs using
> functional dependencies into programs using family
synonyms instead.
http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html#equality-constraints

And the forms of constraint seem quite sophisticated.
I was surprised (pleased) I could do this:

{-# LANGUAGE   MultiParamTypeClasses, TypeFamilies,
                             FlexibleInstances #-}

type family F a

class (F a ~ (b, c) ) => C a b c   where       -- (b c) !!
  f1 :: a -> b
  f2 :: a -> c

Uses of `f1` happily improve the type for `b`.
Uses of `f2` happily improve the type for `c`.

But I didn't declare a Functional Dependency.
(It seems to do no harm if I add `| a -> b c`.)

GHC's behaviour seems stronger than a "simple translation".
It seems entirely equivalent to a FunDep.

Or is there something I'm missing?
(I could have overlapping instances,
 but only providing the equations for
 type family `F` are confluent.)

Are there restrictions on the form of Equality Constraints
to get them to behave as FunDeps?
(It's not merely a bare typevar on one side.)

AntC
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

Richard Eisenberg-4
I'm not quite sure what a restriction on (~) might be, but (~) is effectively declared as

> class a ~ b | a -> b, b -> a

So I agree with your observations.

Richard


> On Apr 27, 2017, at 8:14 PM, Anthony Clayden <[hidden email]> wrote:
>
> The docos say [User Guide 10.14.1. on Equality Constraints]
>
>> Equality constraints can also appear in class and instance
> contexts.
>> The former enable a simple translation of programs using
>> functional dependencies into programs using family
> synonyms instead.
> http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html#equality-constraints
>
> And the forms of constraint seem quite sophisticated.
> I was surprised (pleased) I could do this:
>
> {-# LANGUAGE   MultiParamTypeClasses, TypeFamilies,
>                             FlexibleInstances #-}
>
> type family F a
>
> class (F a ~ (b, c) ) => C a b c   where       -- (b c) !!
>  f1 :: a -> b
>  f2 :: a -> c
>
> Uses of `f1` happily improve the type for `b`.
> Uses of `f2` happily improve the type for `c`.
>
> But I didn't declare a Functional Dependency.
> (It seems to do no harm if I add `| a -> b c`.)
>
> GHC's behaviour seems stronger than a "simple translation".
> It seems entirely equivalent to a FunDep.
>
> Or is there something I'm missing?
> (I could have overlapping instances,
> but only providing the equations for
> type family `F` are confluent.)
>
> Are there restrictions on the form of Equality Constraints
> to get them to behave as FunDeps?
> (It's not merely a bare typevar on one side.)
>
> AntC
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

AntC
In reply to this post by AntC
> On Sat Apr 29 02:23:10 UTC 2017, Richard Eisenberg wrote:
>
> I'm not quite sure what a restriction on (~) might be,

Thanks Richard,

I was thinking that FunDeps are restricted to bare type
vars.

I can't write either of these:

> class C a b c | a -> (b, c)   -- per my O.P. (~)

> class C a b c | a -> (b c)

So it's the one place where type vars `b c` like this:

> class C a b c | a -> b c

doesn't mean applying `b` to `c`.


> but (~) is effectively declared as
>
> > class a ~ b | a -> b, b -> a
>
> So I agree with your observations.

Aha! So I could equivalently go:

> class EqC a b | a -> b, b -> a
>
> class (EqC a (b, c)) => C a b c where ...
>   -- needs FlexibleInstances

And that does indeed work equivalently to the (~).
Again, I haven't put FunDeps on class `C`.

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.)


AntC

> > On Apr 27, 2017, at 8:14 PM, Anthony Clayden
> > <[hidden email]> wrote:
> > The docos say [User Guide 10.14.1. on Equality
> > Constraints]
> >> Equality constraints can also appear in class and
> > instance contexts.
> >> The former enable a simple translation of programs
> >> using functional dependencies into programs using
> > family synonyms instead.
> >
>
http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html#equality-constraints

> >
> > And the forms of constraint seem quite sophisticated.
> > I was surprised (pleased) I could do this:
> >
> > {-# LANGUAGE   MultiParamTypeClasses, TypeFamilies,
> >                             FlexibleInstances #-}
> >
> > type family F a
> >
> > class (F a ~ (b, c) ) => C a b c   where       -- (b c)
> >  !! f1 :: a -> b
> >  f2 :: a -> c
> >
> > Uses of `f1` happily improve the type for `b`.
> > Uses of `f2` happily improve the type for `c`.
> >
> > But I didn't declare a Functional Dependency.
> > (It seems to do no harm if I add `| a -> b c`.)
> >
> > GHC's behaviour seems stronger than a "simple
> > translation". It seems entirely equivalent to a FunDep.
> >
> > Or is there something I'm missing?
> > (I could have overlapping instances,
> > but only providing the equations for
> > type family `F` are confluent.)
> >
> > Are there restrictions on the form of Equality
> > Constraints to get them to behave as FunDeps?
> > (It's not merely a bare typevar on one side.)
> >
> > AntC
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > [hidden email]
> >
>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

AntC
In reply to this post by AntC
> 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/35260970#35260970

"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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

Richard Eisenberg-4

> On Apr 30, 2017, at 6:37 AM, Anthony Clayden <[hidden email]> 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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

Brandon Allbery
On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg <[hidden email]> wrote:
> On Apr 30, 2017, at 6:37 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

Richard Eisenberg-4
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 <[hidden email]> wrote:

On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg <[hidden email]> wrote:
> On Apr 30, 2017, at 6:37 AM, Anthony Clayden <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

AntC
In reply to this post by AntC
> On Sun Apr 30 19:35:17 UTC 2017 Brandon Allbery wrote:

>> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg wrote:
>>>
>>> On Apr 30, 2017, at 6:37 AM, Anthony Clayden wrote:
>>> Is that behaviour officially documented somewhere?
>>
>> Not that I can find. ...
>
> ... the originally cited behavior of
> equality constraints could also stand to be documented.
..

Thanks Brandon, I've added a request to #10431 [q.v.].

Actually, the required flags are documented,
just in an obscure place.
Anyway it's not too bad:
GHC's error message tells you what to do.


AntC
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

AntC
In reply to this post by AntC
> On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg wrote:

> 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!

Thanks for the invite ;-).

OK. Done. See #13657.

I've put suggested wording, please improve!

The trickier problem is where to put the wording;
the 'feature' is really at the intersection of
several extensions.

>
> Some relevant discussion on this point is on
> https://ghc.haskell.org/trac/ghc/ticket/10431
>

I've linked my ticket to that one.


AntC

>
> > On Apr 30, 2017, at 3:35 PM, Brandon Allbery wrote:
>>> On Sun, Apr 30, 2017 at 3:31 PM, Richard Eisenberg
wrote:
>>>> 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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

AntC
In reply to this post by AntC
Now that I've got the bit between my teeth ...

Superclass constraints are not subject to the Paterson
conditions.
IOW I can write superclass constraints
that are not permitted as instance constraints.
(Superclass constraints are required to be
 non-cyclic, which ensures they're terminating.)

Is that worth adding to the docos?

Something like this is OK:

> class (F a b ~ b) => C a b ...
> -- equivalently
> class (D a b b) => C a b ...

Can I think of a use for that? Maybe ...

Sometimes even though you have a type function,
you can use knowledge of the result
to 'improve' the parameters.

The classic case is adding type-level Naturals.

Maybe even type-level Boolean And:
- if the result is True, so must be the params.
- if the result is False,
  and you know one param is True,
  the other must be False.
- but that can't be a function, because
  if the result is False
  and you know one param is False,
  that tells nothing about the other param.


AntC

> > On Sun Apr 30 19:45:34 UTC 2017, Richard Eisenberg
> wrote:
>
> > 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!
>
> OK. Done. See #13657.
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Superclass Equality constraints cp FunDeps

Richard Eisenberg-4

> On May 7, 2017, at 8:42 PM, Anthony Clayden <[hidden email]> wrote:
>
> Is that worth adding to the docos?

The best way to evaluate this is to submit a concrete patch -- better if it’s a patch directly to the manual than just a note on Trac. (Better ==> it will be adopted sooner.) A great way to do this is to create a ticket on Trac and then post a patch on Phabricator. (https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs has some instructions)

Thanks!
Richard
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Loading...