On 09/13/13 01:51, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević <blama...@acanac.net
<mailto:blama...@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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
