[Haskell-cafe] Data.Binary Endianness

Sven Panne sven.panne at aedion.de
Tue Sep 11 03:10:17 EDT 2007


On Tuesday 11 September 2007 08:14, Don Stewart wrote:
> sven.panne:
> > 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).

Cheers,
   S.


More information about the Haskell-Cafe mailing list