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
On Sun, 01 Sep 2013 23:27:20 +0400, Henning Thielemann < lemming@henning-thielemann.de**> wrote:
On Sun, 1 Sep 2013, Artyom Kazak wrote:
On Sun, 01 Sep 2013 22:55:10 +0400, Henning Thielemann <
lemming@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@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries