proposal/RFC: add bSwap to base in Data.Bits
ekmett at gmail.com
Fri May 17 20:59:31 CEST 2013
I agree with every one of Ian's points here.
Just bolting the functions in non-overloaded in Data.Word would be a useful
starting point and side-steps concerns of what it means when you have
(Finite)Bits instances that don't evenly divide into bytes, etc.
On Fri, May 17, 2013 at 2:37 PM, Ian Lynagh <ian at well-typed.com> wrote:
> On Thu, May 16, 2013 at 11:36:46AM +0200, Vincent Hanquez wrote:
> > On Thu, May 16, 2013 at 05:07:51AM -0400, Edward Kmett wrote:
> > > Henning has a point.
> > >
> > > EndianSensitive is arguably the more appropriate notion.
> > Yes, Bits is not necessarily the best fit in term of naming or feature,
> > nothing close to EndianSensitive is in base.
> There's no reason that the recommended interface to the primitives needs
> to be in base. It would be a little unfriendly to only export the
> primitives, but we could just export
> byteSwap16 :: Word16 -> Word16
> byteSwap32 :: Word32 -> Word32
> byteSwap64 :: Word64 -> Word64
> and leave it up to packages like data-endian to provide a more
> user-friendly interface.
> The problem with adding a Bytes class is there are various questions,
> like "should there be an instance Bytes a => Bytes [a]?", "should there
> be a toWord8s :: a -> [Word8]" method?", and "would Word8s be a better
> name for the class?". If the class goes into base, then it's a lot
> harder to change the answers to these questions (and, indeed, to the
> questions that we don't think to ask before the class is in a released
> I think that adding the functions above, probably to Data.Word, would be
> my preference.
> Oh, and for the record, I also prefer "byteSwap" to "bswap", and dislike
> using (Finite)Bits for this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries