<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br>On Fri, Jul 10, 2015 at 9:46 AM, Patrick Chilton <span dir="ltr"><<a href="mailto:chpatrick@gmail.com" target="_blank">chpatrick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Take a look at <a href="https://hackage.haskell.org/package/mono-traversable" target="_blank">mono-traversable</a>. pure' is singleton and Foldable' is MonoFoldable.</div></blockquote></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 10, 2015 at 9:47 AM, Patrick Chilton <span dir="ltr"><<a href="mailto:chpatrick@gmail.com" target="_blank">chpatrick@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Actually Applicative' is <a href="https://hackage.haskell.org/package/mono-traversable-0.9.2.1/docs/Data-MonoTraversable.html#t:MonoPointed" target="_blank">MonoPointed</a>.</div></blockquote></div><br>Thank you! Indeed, I was able to re-implement the library deferring to MonoFoldable and MonoPointed and then collapse the whole thing to a single module with two functions that automatically work with all suitable input and output types.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In terms of the package (and since I'll be bumping the major version) I don't think the specialized modules are needed any more, since they're just a small subset of the combinatorial input/output space. Or is there a tangible benefit to users in providing more concretely typed versions for those (unusual?) cases where the return type is ambiguous? So, given:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">    type Input i e = (MonoFoldable i, Element i ~ e)<br></div><div class="gmail_extra">    type Output o e = (MonoPointed o, Element o ~ e, Monoid o)</div><div class="gmail_extra"><br></div></div><div class="gmail_extra">    encode :: forall i o. (Input i Word8, Output o Char) => i -> o</div><div><div>    decode :: forall i o. (Input i Char, Output o Word8) => i -> o</div></div><div><br></div><div class="gmail_extra">Does including and exposing the following...</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">    encodeToString :: Input i Word8 => i -> [Char]</div><div class="gmail_extra">    decodeToBytes :: Input i Char => i -> [Word8]<br></div><div class="gmail_extra">    encodeBytes :: Output o Char => [Word8] -> o<br></div><div class="gmail_extra">    decodeString :: Output o Word8 => [Char] -> o<br></div><div class="gmail_extra">    encodeBytesToString :: [Word8] -> [Char]<br></div><div class="gmail_extra">    decodeStringToBytes :: [Char] -> [Word8]<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">...add any value, being trivially defined as equal to the generic version? (Plus, the explosion doubles with another dimension like lazy vs. strict.) I don't see much advantage over e.g. (encode ws :: String) for the first case.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks again,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://alva.ro" style="font-family:arial">Alvaro</a><br></div></div><div class="gmail_extra"><div><div dir="ltr"><div style="font-family:arial;font-size:small"><br></div></div></div>
</div></div>