mapM_ for bytestring

[Carter Schonwald]

a simpler subproblem is theres no Bystring.*.Unsafe.Internal module that
lets Bytestring library clients to (at their own risk) add new fusion rules.

Isn't this "private fusion framework" shenanigans where lib clients can't
add new things that fuse well a recurrent problem making it difficult to
have down stream users have their own performant extensions?


On Sun, Sep 1, 2013 at 3:42 PM, Artyom Kazak <yom at artyom.me> wrote:

> On Sun, 01 Sep 2013 23:27:20 +0400, Henning Thielemann <
> lemming at henning-thielemann.de**> wrote:
>
>
>> On Sun, 1 Sep 2013, Artyom Kazak wrote:
>>
>>  On Sun, 01 Sep 2013 22:55:10 +0400, Henning Thielemann <
>>> lemming at henning-thielemann.de**> wrote:
>>>
>>>  A possible solution might be fusion rules for ByteString.unpack and
>>>> mapM_.
>>>>
>>>
>>> Except that such rules would require a hand-written version of mapM_
>>> anyway.
>>>
>>> I agree that it can be written, it’s just that I don’t see why it should
>>> be
>>> in some obscure place instead of Data.ByteString.
>>>
>>
>> This rule should of course be part of Data.ByteString. RULES are similar
>> to class instances and like orphan instances, orphan rules are a bad idea.
>>
>
> It still doesn’t solve the problem quite like adding mapM_ does. Rules
> aren’t documented anywhere; why would the programmer expect `mapM_ .
> unpack` to fuse?
>
> Moreover, it violates the existing structure of bytestring package. For
> instance, functions like `last` and `maximum` could be implemented as rules
> in the same way, but they’re included in Data.ByteString (for good, I’d
> say).
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130901/0e190e85/attachment.htm>