[Haskell-cafe] [ANN] base91

[Alvaro J. Genial]

Howdy,

I'd like to announce a first version of base91
<http://hackage.haskell.org/package/base91>, a Haskell package to enable
the encoding and decoding of data in Base91 format, as documented in its
specification <http://base91.sourceforge.net>. The main benefits of said
scheme are a good reduction in overhead (from 31% up to 58%) when compared
to Base64 due to the clever use of two printable ASCII characters
(consuming 16 bits) to encode 13 arbitrary bits, as well as neither need
for nor ambiguity over padding or alphabets.

It includes support for...

- Plain Strings (module Codec.Binary.Base91.String)
- Data.ByteString (module Codec.Binary.Base91.ByteString)
- Data.Text (module Codec.Binary.Base91.Text)
- The latter two combined (module Codec.Binary.Base91.Efficient)
- Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy)
- Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy)
- The latter two combined (module Codec.Binary.Base91.Efficient.Lazy)

...which are all just concretely typed versions of the generic
implementation in Codec.Binary.Base91.

I had fun exploring some of the latest GHC extensions, as evidenced by
Codec.Binary.Base91.Control, which relies on a certain amount of type
trickery to reconcile the incongruence between monomorphic containers and
the standard type classes.

Anyway, suggestions are very welcome. In particular, I'm interested in:

1. Whether the generic decode and encode signatures can be simplified or
improved elsehow.
2. Whether there already exist classes similar in purpose to Applicative'
and Foldable'.
3. Whether it makes sense to offer decode and encode variants that use lazy
(left) folds--currently folding is always strict, even with lazy types.

(Testing comes nearly free courtesy of QuickCheck and the identity property
of decode . encode, plus a couple of concrete examples. Please open an
issue or otherwise let me know if you find a bug.)

Thank you,

Alvaro <http://alva.ro>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150709/e18cbd1c/attachment.html>