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

13 Sep 2013


      ...
On 09/13/13 01:51, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević mailto:blamario@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.