Alternative.some and NonEmpty

[Edward Kmett]

I'm also in the "if we're going to do this, it should probably be a new
function" camp. e.g. `some1`. I'm kinda neutral on adding it at all at this
point, but if we do it, it should probably be done along these lines.

As for using a semigroup based implementation, its performance is, sadly,
rather awful for constructing `NonEmpty` lists, and more damning, you have
no law relating the 'pure' or whatever you're using to create values and
the Semigroup you're using to glue them together, so it only works for
NonEmpty on a purely ad-hoc type-by-type basis. That signature isn't one we
want as evidenced by the fact that if you pick m = Maybe you sure as heck
won't get anything like what you expect! This is the pointed problem all
over again. I'm very strongly -1 on that variant of the proposal.

-Edward


On Tue, Mar 7, 2017 at 2:02 PM, Sven Panne <svenpanne at gmail.com> wrote:

> 2017-03-07 18:11 GMT+01:00 Henning Thielemann <
> lemming at henning-thielemann.de>:
>
>>
>> On Tue, 7 Mar 2017, Mario Blažević wrote:
>>
>>> [...]You're correct on both counts, sorry about that. It would have to be
>>>
>>> genericMany, genericSome ::
>>>  (Alternative f, Applicative m, Semigroup (m a)) => f a -> f (m a)
>>>
>>> once Semigroup is in base.
>>>
>>
>> But then, for genericMany, Monoid would be appropriate, again. :-)
>>
>
> I think this discussion alone is enough of a hint that there is a need for
> a broader discussion to come up with coherent story regarding NonEmpty in
> general. ;-) Focusing on one or two functions alone will probably do more
> harm than improve the overall situation.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170307/d112aae0/attachment-0001.html>