Arg has unlawful instances

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Arg has unlawful instances

David Feuer
Foldable, Traversable, Bifoldable, and Bitraversable instances of Data.Semigroup.Arg don't respect ==.

For example, Arg () 1 == Arg () 2 = True, but sum (Arg () 1) = 1 and sum (Arg () 2) = 2.

I believe the best solution is to remove the Traversable and Bitraversable instances, and define

    foldMap _ _ = mempty
    bifoldMap f _ (Arg a _) = a

There also needs to be some documentation about the fact that the Arg constructor allows inspection that does not respect Eq.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Arg has unlawful instances

Henning Thielemann

On Fri, 10 May 2019, David Feuer wrote:

> There also needs to be some documentation about the fact that the Arg
> constructor allows inspection that does not respect Eq.

This follows from Arg's purpose.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Arg has unlawful instances

Edward Kmett-2
-1

I agree with Henning on this one.

(==) provides an equivalence relation.

Despite the addition of some vocabulary in base 4.12 about how (==) "should" be structural, that is at odds with Arg's actual purpose.

I'd rather argue that the attempted refinement of (==)'s documentation was rather overzealous than that Arg as it is defined is wrong.

The instances are useful and follow the intent of the classes, just not the extra paragraph that was bolted on sideways to the text describing Eq.

-Edward

On Sat, May 11, 2019 at 9:30 AM Henning Thielemann <[hidden email]> wrote:

On Fri, 10 May 2019, David Feuer wrote:

> There also needs to be some documentation about the fact that the Arg
> constructor allows inspection that does not respect Eq.

This follows from Arg's purpose.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Arg has unlawful instances

chessai .
In what way is the documentation for Eq (as of base 4.12) overzealous, and how would you suggest it be changed?

Thanks

On Sat, May 11, 2019, 3:35 AM Edward Kmett <[hidden email]> wrote:
-1

I agree with Henning on this one.

(==) provides an equivalence relation.

Despite the addition of some vocabulary in base 4.12 about how (==) "should" be structural, that is at odds with Arg's actual purpose.

I'd rather argue that the attempted refinement of (==)'s documentation was rather overzealous than that Arg as it is defined is wrong.

The instances are useful and follow the intent of the classes, just not the extra paragraph that was bolted on sideways to the text describing Eq.

-Edward

On Sat, May 11, 2019 at 9:30 AM Henning Thielemann <[hidden email]> wrote:

On Fri, 10 May 2019, David Feuer wrote:

> There also needs to be some documentation about the fact that the Arg
> constructor allows inspection that does not respect Eq.

This follows from Arg's purpose.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Arg has unlawful instances

Matt
IMO, requiring substitivity (forall a b. if a == b then forall f. f a == f b) is a pretty onerous condition for Eq as it is used in practice. Usually type class laws only govern how the type class methods interact with each other and with super classes. The substitutivity law places a requirement on the entire publicly exported interface for a type. The `Set` type in containers is in violation of this law as well (with `f = splitRoot`).

Laws are primarily sold to developers as a means of refactoring fearlessly - eg i can rewrite `fmap f . fmap g` into `fmap (f . g)` without altering the meaning of the given program. I'm not sure which refactors are possible with the substitutivity law.

Matt Parsons


On Sat, May 11, 2019 at 8:32 AM chessai . <[hidden email]> wrote:
In what way is the documentation for Eq (as of base 4.12) overzealous, and how would you suggest it be changed?

Thanks

On Sat, May 11, 2019, 3:35 AM Edward Kmett <[hidden email]> wrote:
-1

I agree with Henning on this one.

(==) provides an equivalence relation.

Despite the addition of some vocabulary in base 4.12 about how (==) "should" be structural, that is at odds with Arg's actual purpose.

I'd rather argue that the attempted refinement of (==)'s documentation was rather overzealous than that Arg as it is defined is wrong.

The instances are useful and follow the intent of the classes, just not the extra paragraph that was bolted on sideways to the text describing Eq.

-Edward

On Sat, May 11, 2019 at 9:30 AM Henning Thielemann <[hidden email]> wrote:

On Fri, 10 May 2019, David Feuer wrote:

> There also needs to be some documentation about the fact that the Arg
> constructor allows inspection that does not respect Eq.

This follows from Arg's purpose.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries