Misleading strictness annotations in Data.List.NonEmpty

[Keith]

There are a couple other ones that I'm less sure about.

cons:
   a <| ~(b :| bs) = a :| b : bs

Unsugared this is
   a <| bs = a :|
      (case bs of b :| _ -> b ) :
      case bs of _ :| bs -> bs

Would this make more sense?
   a <| bs = a :| case bs of b :| bs' -> b : bs'

Then 
   cons x undefined = x :| undefined
not 
   x :| undefined : undefined


groupBy1 matches strictly, could be lazy. (Is this a performance issue or an oversight?)
—
Sent from my phone with K-9 Mail.

On January 8, 2021 6:36:58 PM UTC, Keith <keith.wygant at gmail.com> wrote:
>Thanks, will do.
>
>On January 8, 2021 5:07:25 PM UTC, David Feuer <david.feuer at gmail.com> wrote:
>>The first one. Neither twiddles nor bangs are useful or add clarity.
>>
>>On Fri, Jan 8, 2021, 11:53 AM Keith <keith.wygant at gmail.com> wrote:
>>
>>> Currently:
>>>
>>> head ~(a :| _) = a
>>> tail ~(_ :| as) = as
>>>
>>> But head and tail are both strict. At best the '~'s have no effect.
>>>
>>> Should I open a PR to change it to
>>>
>>> head (a :| _) = a
>>> tail (_ :| as) = as
>>>
>>> or maybe even more clearly
>>>
>>> head !(a :l _) = a
>>> tail !(_ :| as) = as
>>>
>>> ?
>>> --Keith
>>> Sent from my phone with K-9 Mail. 
>
>
>Good to know! Wasn't aware that that was in the works.
>
>And sorry for accidentally threading this onto something unrelated.
>
>-- Keith
>Sent from my phone with K-9 Mail.
>
>On January 8, 2021 5:13:31 PM UTC, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>>
>>On Fri, 8 Jan 2021, Keith wrote:
>>
>>> Currently:
>>> 
>>> head ~(a :| _) = a
>>> tail ~(_ :| as) = as
>>> 
>>> But head and tail are both strict. At best the '~'s have no effect.
>>> 
>>> Should I open a PR to change it to
>>> 
>>> head (a :| _) = a
>>> tail (_ :| as) = as
>>> 
>>> or maybe even more clearly
>>> 
>>> head !(a :l _) = a
>>> tail !(_ :| as) = as
>>> 
>>> ?
>>
>>The last one would trigger the "redundant bang pattern" warning that is 
>>going to be implemented/released:
>>    https://gitlab.haskell.org/ghc/ghc/issues/17340
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210108/fbd71cee/attachment.html>