[Haskell-cafe] Monomorphic containers, Functor/Foldable/Traversable WAS: mapM_ for bytestring

[Mario Blažević]

> On 09/13/13 01:51, Michael Snoyman wrote:
> On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević <blamario at acanac.net 
> <mailto:blamario at acanac.net>> wrote:
>
>     On 09/11/13 19:37, John Lato wrote:
>
>
>         3.  I'm not entirely sure that the length* functions belong
>         here.  I
>         understand why, and I think it's sensible reasoning, and I
>         don't have a
>         good argument against it, but I just don't like it.  With
>         those, and
>         mapM_-like functions, it seems that the foldable class is
>         halfway to
>         being another monolithic ListLike.  But I don't have any
>         better ideas
>         either.
>
>
>             If monolithic classes bother you, my monoid-subclasses
>     package manages to break down the functionality into several
>     classes. One big difference is that everything is based off Monoid
>     rather than Foldable, and that has some big effects on the interface.
>
>
>
> I'd point out what I'd consider a bigger difference: the type 
> signatures have changed in a significant way. With MonoFoldable, 
> folding on a ByteString would be:
>
>     (Word8 -> b -> b) -> b -> ByteString -> b
>
> With monoid-subclasses, you get:
>
>     (ByteString -> b -> b) -> b -> ByteString -> b
>
> There's certainly a performance issue to discuss, but I'm more worried 
> about semantics. Word8 tells me something very specific: I have one, 
> and precisely one, octet. ByteString tells me I have anywhere from 0 
> to 2^32 or 2^64  octets. Yes, we know from context that it will always 
> be of size one, but the type system can't enforce that invariant.

     All true, but we can also use this generalization to our advantage. 
For example, the same monoid-subclasses package provides ByteStringUTF8, 
a newtype wrapper around ByteString. It behaves the same as the plain 
ByteString except its atomic factors are not of size 1, instead it folds 
on UTF-8 encoded character boundaries. You can't represent that in 
Haskell's type system.