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@artyom.me> wrote:

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/libraries