Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

[Simon Meier]

Hi Mikhail,

I've never used these functions in my code. So I cannot judge their
usefulness. Having inspected your patch, I see the following points
for optimization:

1. The clarity of the code of Data.ByteString.unsnoc would profit from
using your 'unsafeInit and unsafeLast' functions.

2. It might well be that some other places could profit from your
'unsafeInit' and 'unsafeLast' functions; e.g., the 'init' and 'last'
functions. It would be great if you also updated other related
definitions.

3. The implementation of Data.ByteString.Lazy.unsnoc is too strict in
my opinion. I would expect it to return 'Just
<combined-init-and-last-computation>', as soon as it has proven that
the ByteString is non-empty. To avoid unnecessary code duplication, it
might make sense to inline only the wrapper and let GHC decide what it
wants to do for the actual worker.


best regards,
Simon

2012/4/2 Mikhail Vorozhtsov <mikhail.vorozhtsov at gmail.com>:
> Hi.
>
> I propose to add the missing counterparts of `uncons` and `unsafeHead/Tail`
> functions to the bytestring library.
>
> Discussion deadline: 2 weeks
>
> The patch is attached.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>