Proposal: unsnoc, unsafeInit and unsafeLast for the bytestring library

Mikhail Vorozhtsov mikhail.vorozhtsov at gmail.com
Tue Apr 3 16:51:44 CEST 2012


On 04/03/2012 08:00 PM, Duncan Coutts wrote:
> On 3 April 2012 13:35, Simon Meier<iridcode at gmail.com>  wrote:
>> 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:
>
>> 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.
>
> Actually, I think it doesn't make sense to provdide unsnoc for lazy
> bytestring at all. It's a bit of a silly operation for lazy
> bytestrings for the same reason as for lists. It's reasonable for
> strict bytestrings because you have the same access to the end of the
> string as the beginning, but the same is not true of lazy bytestrings.
Hm, why `(,) <$> init <*> last` makes less sense than `init` and `last` 
themselves?



More information about the Libraries mailing list