Howdy,

I'd like to announce a first version of base91, a Haskell package to enable the encoding and decoding of data in Base91 format, as documented in its specification. 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,