Alternative.some and NonEmpty

[Edward Kmett]

Even better,

http://hackage.haskell.org/package/base-4.9.1.0/docs/Data-List-NonEmpty.html#v:some1

is already there in base! ;)

On Tue, Mar 7, 2017 at 10:21 PM, Tony Morris <tmorris at tmorris.net> wrote:

> Related: https://hackage.haskell.org/package/semigroups-0.18.1/
> docs/src/Data.List.NonEmpty.html#some1
>
> On Wed, Mar 8, 2017 at 1:18 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20170308/a597fb48/attachment.html>