[Haskell-cafe] blaze-builder and FlexibleInstances in code that aims to become part of the Haskell platform

[Antoine Latter]

On Thu, May 19, 2011 at 3:06 PM, Simon Meier <iridcode at gmail.com> wrote:

> The core problem that drove me towards this solution is the abundance
> of different IntX and WordX types. Each of them requiring a separate
> Write for big-endian, little-endian, host-endian, lower-case-hex, and
> uper-case-hex encodings; i.e., currently, there are
>
> int8BE   :: Write Int8
> int16BE :: Write Int16
> int32BE :: Write Int32
> ...
> hexLowerInt8 :: Write Int8
> ...
>
> and so on. As you can see
> (http://hackage.haskell.org/packages/archive/blaze-builder/0.3.0.1/doc/html/Blaze-ByteString-Builder-Word.html)
> this approach clutters the public API quite a bit. Hence, I'm thinking
> of using a separate type-class for each encoding; i.e.,
>

If Johan's work on Data.Binary and rewrite rules works out, then it
would cut the exposed API in half, which helps.

We could then use the module and package system to further keep the
API clean, with builders which output a specific encoding could live
in separate modules. This could also keep the names of the functions
short, as well.

That would require coming up with logical divisions for the functions
you're creating, and I don't understand the big picture enough to help
with that.

>  class BigEndian a where
>    bigEndian :: Write a
>
> This collapses the big-endian encodings of all 10 bounded-size (signed
> and unsigned) integer types under a single name with a well-defined
> semantics. Moreover, it's standard Haskell 98. For the hex-encodings,
> I'm thinking about providing type-classes
>
>  class HexLower a where
>    hexLower :: Write a
>
>  class HexLowerNoLead a where
>    hexLowerNoLead :: Write a
>
>  ...
>
> for ASCII encoding and each of the standard Unicode encodings in a
> separate module. The user can then select the right ones using
> qualified imports. In most cases, he won't even need qualification, as
> mixing different character encodings is seldomly used.
>

I think we may be at cross-purposes here, and might not even be
discussing the same thing - I would imagine that any sort of 'Builder'
type included in the bytestring package would only provide the core
combinators for packing data into low-level binary formats, so
discussions about text encoding issues, converting to hexidecimal and
Html escaping are going above my head.

This seems like what the 'text' package was written for - to separate
out the construction of textual data from choosing its encoding.

Are there use-cases where the 'text' package is too slow for this sort
of approach?

Take care,
Antoine

> What do you think about such an interface? Is there another catch
> hidden, I'm not seeing? BTW, note that Writes are a pure compile time
> abstraction and are thought to be completely inlined. In typical, uses
> cases there's no efficiency overhead stemming from these typeclasses.
>
> best regards,
> Simon
>