[Haskell-cafe] [ANN] base91
lambda.fairy at gmail.com
Thu Aug 13 10:32:30 UTC 2015
Sorry about the late response, but is this overloading truly necessary?
`Text.unpack` isn't that much to type, and I'm not sure if the
benefits of overloading outweigh the cognitive load. `String` and
`[Word8]` are rare in production code, and not everyone uses (or is
aware of) mono-traversable.
As a data point, the base16-bytestring and base64-bytestring packages
only expose functions of type `ByteString -> ByteString`.
On Sat, Jul 11, 2015 at 7:11 AM, Alvaro J. Genial <genial at alva.ro> wrote:
> On Fri, Jul 10, 2015 at 9:46 AM, Patrick Chilton <chpatrick at gmail.com>
>> Take a look at mono-traversable. pure' is singleton and Foldable' is
> On Fri, Jul 10, 2015 at 9:47 AM, Patrick Chilton <chpatrick at gmail.com>
>> Actually Applicative' is MonoPointed.
> 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.
> 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:
> type Input i e = (MonoFoldable i, Element i ~ e)
> type Output o e = (MonoPointed o, Element o ~ e, Monoid o)
> encode :: forall i o. (Input i Word8, Output o Char) => i -> o
> decode :: forall i o. (Input i Char, Output o Word8) => i -> o
> Does including and exposing the following...
> encodeToString :: Input i Word8 => i -> [Char]
> decodeToBytes :: Input i Char => i -> [Word8]
> encodeBytes :: Output o Char => [Word8] -> o
> decodeString :: Output o Word8 => [Char] -> o
> encodeBytesToString :: [Word8] -> [Char]
> decodeStringToBytes :: [Char] -> [Word8]
> ...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.
> Thanks again,
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Chris Wong (https://lambda.xyz)
"Humans find such fascinating ways to waste their time."
-- Steven Universe
More information about the Haskell-Cafe