Skip to content

instance (Applicative f, Semigroup f) => Semigroup (NonEmpty f a) #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wereHamster opened this issue Nov 9, 2016 · 10 comments
Closed

Comments

@wereHamster
Copy link

Would be useful to concatenate two NonEmpty Array a types together, for example. Is there a reason why it doesn't exist?

@paluh
Copy link
Contributor

paluh commented Oct 17, 2017

Is anything wrong with @wereHamster's proposition? Should I provide pull request?

@damncabbage
Copy link

damncabbage commented Nov 13, 2017

I have the same question; I've written a non-typeclass version of append already for our own (internal) Prelude.

@matthewleon
Copy link
Contributor

For some reason the assumption in such an implementation that pure means singleton (I'm assuming that is what your Applicative constraint is for) rubs me the wrong way. Can you prove that this always end up being law-abiding?

@wereHamster
Copy link
Author

Maybe Applicative is not needed, I don't know anymore.

@paluh
Copy link
Contributor

paluh commented Jan 17, 2018

@matthewleon

Taking this implementation:

append   a f. Semigroup (f a)  Applicative f  NonEmpty f a  NonEmpty f a  NonEmpty f a
append (NonEmpty a1 f1) (NonEmpty a2 f2) = NonEmpty a1 (f1 <> pure a2 <> f2)

We have:

 NonEmpty a1 f1 <> (NonEmpty a2 f2 <> NonEmpty a3 f3)
 -- using append
 NonEmpty a1 f1 <> NonEmpty a2 (f2 <> pure a3 <> f3)
 -- using append
 NonEmpty a1 (f1 <> pure a2 <> (f2 <> pure a3 <> f3))
 -- using associativity of f
 NonEmpty a1 ((f1 <> pure a2 <> f2) <> pure a3 <> f3)
 -- using append
 NonEmpty a1 (f1 <> pure a2 <> f2) <> NonEmpty a3 f3
 -- using append
 (NonEmpty a1 f1 <> NonEmpty a2 f2) <> NonEmpty a3 f3

So it seems that Associativity holds.

@paluh
Copy link
Contributor

paluh commented Jan 17, 2018

P.S.
But I fully understand your doubts about Applicative as it is too strong constraint in this context, because we don't really need Apply...

@paluh
Copy link
Contributor

paluh commented Jan 17, 2018

On the other hand pure without any additional operations seems to be "lawless", so I'm not sure if there is any sensible alternative...

ahansen90 pushed a commit to ahansen90/purescript-nonempty that referenced this issue Mar 31, 2019
@ahansen90
Copy link

Is there any reason we couldn't just implement this and swap it out for a weaker constraint afterwards?

@hdgarrood
Copy link
Contributor

The only problem with this is that we don't know that pure will behave sensibly alongside <>, because we don't have any laws which govern their behaviour. Then again, this is a valid semigroup as proved by @paluh, and in practice this data type is probably most often used with types like Array or List which will behave sensibly, so I think adding this instance probably does make sense.

jmatsushita pushed a commit to jmatsushita/purescript-nonempty that referenced this issue Oct 5, 2021
jmatsushita added a commit to jmatsushita/purescript-nonempty that referenced this issue Oct 19, 2021
@JordanMartinez
Copy link
Contributor

Closed by #50.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants