Monoid for ZipList

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

Monoid for ZipList

박신환

As instance Alternative ZipList is defined since 4.11.0.0:

instance Alternative ZipList where
    empty = ZipList []
    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)

It seems perfectly fine to make Monoid for ZipList as followings:

instance Semigroup a => Semigroup (ZipList a) where
ZipList [] <> ZipList ys = ZipList ys
ZipList xs <> ZipList [] = ZipList xs
ZipList (x:xs) <> ZipList (y:ys) = ZipList (x <> y : ZipList xs <> ZipList ys)

instance Semigroup a => Monoid (ZipList a) where
mempty = ZipList []


Note that this semantic is similar to that of Maybe​.

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

Re: Monoid for ZipList

Andrew Martin
There is another possible instance. We can instead write:

    instance Semigroup a => Semigroup (ZipList a) where
      (<>) = liftA2 (<>)
    instance Monoid a => Monoid (ZipList a) where
      mempty = pure mempty

This behaves differently, and it is also law-abiding.

On Thu, May 3, 2018 at 5:22 AM, 박신환 <[hidden email]> wrote:

As instance Alternative ZipList is defined since 4.11.0.0:

instance Alternative ZipList where
    empty = ZipList []
    ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs) ys)

It seems perfectly fine to make Monoid for ZipList as followings:

instance Semigroup a => Semigroup (ZipList a) where
ZipList [] <> ZipList ys = ZipList ys
ZipList xs <> ZipList [] = ZipList xs
ZipList (x:xs) <> ZipList (y:ys) = ZipList (x <> y : ZipList xs <> ZipList ys)

instance Semigroup a => Monoid (ZipList a) where
mempty = ZipList []


Note that this semantic is similar to that of Maybe​.

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




--
-Andrew Thaddeus Martin

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

Re: Monoid for ZipList

박신환

I aim to make the semantic consistent compared to that of other type classes (here Maybe).

 

Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible. 

 

 

-----Original Message-----
From: "Andrew Martin"<[hidden email]>
To: "박신환"<[hidden email]>;
Cc: "Haskell Libraries"<[hidden email]>;
Sent: 2018-05-03 (목) 21:05:24
Subject: Re: Monoid for ZipList
 

There is another possible instance. We can instead write:
 
    instance Semigroup a => Semigroup (ZipList a) where
      (<>) = liftA2 (<>)
    instance Monoid a => Monoid (ZipList a) where
      mempty = pure mempty
 
This behaves differently, and it is also law-abiding.
 

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

Re: Monoid for ZipList

Edward Kmett-2
It is worth noting that Maybe a and [a] are rather special cases. The former is the monoid you get from adjoining a unit to a semigroup. The latter is the free monoid. Most other monoids for things wrapped in an applicative are either based on the Alternative instance which inherently provides a monoidal structure or based on lifting a monoid pointwise into the data type. 

Here we have at least 3-4 possible, quite reasonable, monoids at play, and no real reason to choose any one of them over the others. In that situation, our general practice thus far has been to resist choosing if a choice hasn't already been made, simply because there is no real manner other than memorization / code inspection for a user to know which instance we happened to pick.

I'm -1 on adding the instance proposed here.

Sent from my iPhone

On May 3, 2018, at 7:40 PM, 박신환 <[hidden email]> wrote:

I aim to make the semantic consistent compared to that of other type classes (here Maybe).

 

Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible. 

 

 

-----Original Message-----
From: "Andrew Martin"<[hidden email]>
To: "박신환"<[hidden email]>;
Cc: "Haskell Libraries"<[hidden email]>;
Sent: 2018-05-03 (목) 21:05:24
Subject: Re: Monoid for ZipList
 

There is another possible instance. We can instead write:
 
    instance Semigroup a => Semigroup (ZipList a) where
      (<>) = liftA2 (<>)
    instance Monoid a => Monoid (ZipList a) where
      mempty = pure mempty
 
This behaves differently, and it is also law-abiding.
 
_______________________________________________
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: Monoid for ZipList

박신환

I'm not refering that Maybe makes Monoid by adding the identity element. I'm refering that the Monoid (Maybe (First a)) have the same semantic as Alternative Maybe.

 

So I'm suggesting that the same semantic should go to Monoid (ZipList (First a)) for Alternative ZipList. 

 

 

-----Original Message-----
From: "Edward Kmett"<[hidden email]>
To: "박신환"<[hidden email]>;
Cc: "Haskell Libraries"<[hidden email]>;
Sent: 2018-05-05 (토) 07:04:05
Subject: Re: Monoid for ZipList
 

It is worth noting that Maybe a and [a] are rather special cases. The former is the monoid you get from adjoining a unit to a semigroup. The latter is the free monoid. Most other monoids for things wrapped in an applicative are either based on the Alternative instance which inherently provides a monoidal structure or based on lifting a monoid pointwise into the data type. 
 
Here we have at least 3-4 possible, quite reasonable, monoids at play, and no real reason to choose any one of them over the others. In that situation, our general practice thus far has been to resist choosing if a choice hasn't already been made, simply because there is no real manner other than memorization / code inspection for a user to know which instance we happened to pick.
 
I'm -1 on adding the instance proposed here.

Sent from my iPhone

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