[Haskell-cafe] Data.Binary Endianness
sven.panne at aedion.de
Tue Sep 11 03:10:17 EDT 2007
On Tuesday 11 September 2007 08:14, Don Stewart wrote:
> > On Monday 10 September 2007 19:50, Thomas Schilling wrote:
> > > [...]
> > > instance Binary MP3 where
> > > get = MP3 <$> getHeader <*> getData -- [*]
> > > where getHeader = do magic <- getWord32le
> > > case magic of
> > > ...
> > Of course this works in the sense that "it compiles", but Binary is
> > conceptually the wrong class to use.
> I wouldn't go as far as saying `wrong', for protocol-specific data types it
> seems reasonable for the Haskell serialisation to use an agreed-upon
> external format, via a Binary instance.
The question is: What is the *human reader* suggested when he sees a signature
like "foo :: Binary a => ... -> a -> ..."? This should probably mean "foo is
using some portable (de-)serialization, but doesn't care about the actual
representation", at least this is how I understand Binary's contract from the
Haddock docs. The example above means something completely different, so I
propose to add another class (e.g. "ExternalBinary", better name needed) to
the binary package for such uses. This class wouldn't have any instances in
the package itself, but at least it would set a standard, so things are
crystal clear when one sees a signature like "blah :: ExternalBinary a
=> ... -> a -> ...".
This situation is very similar to the OO-world, where class inheritance is
often overused, just because it looks so handy when written initially and
delegation/aggregation/... would be the conceptually right way (i.e.
implementation hierarchy vs. interface hierarchy).
More information about the Haskell-Cafe