Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Little-Endian, Big-Endian, and Byteswap Functions and Classes #412

Open
andrewthad opened this issue Mar 26, 2024 · 0 comments
Open

Comments

@andrewthad
Copy link
Collaborator

In #409 it was discovered that @raehik and I had independently developed the same interface (modulo naming) for talking about fixed-endianness elements in a primitive array. The interface looks like this (I'm using my names for these, but I don't think there are great names):

data ByteOrder = LittleEndian | BigEndian -- defined in base
newtype Fixed :: ByteOrder -> Type -> Type where ...
class FixedOrdering (b :: ByteOrder) where ... -- only has two instances
class Bytes a where
  toLittleEndian :: a -> a
  toBigEndian :: a -> a
instance (FixedOrdering b, Prim a, Bytes a) => Prim (Fixed b a) where ...

And now we can do things like this:

myLittleEndianW32s :: PrimArray (Fixed 'LittleEndian Word32)

And then there are other modules like Data.Primitive.ByteArray.LittleEndian that illustrate what can be done with just the Bytes class and none of the other stuff.

The question I'd like to pose is: Does any/all/some/none of this functionality belong in primitive?

The argument in favor I'd like to break into two parts:

  1. The usual arguments for consolidation: better discoverability, improved trust (trust in both the security sense and in the "is this code even correct" sense), less dependencies for users
  2. An argument that the scope of primitive (which is not actually defined anywhere even informally) includes byte swapping. Byte swapping is a fundamental operation on fixed-byte-width types. GHC offers both these primops and knowledge of the target system's byte order. What naturally falls out of the intersection of these features is the ability to talk about arrays whose elements have a fixed endianness.

The argument against is the usual argument against consolidation: users can already use the byte-order library as it is today, introducing additional features introduces cognitive overhead, version bumps are more likely to be needed since they are more things that could change, etc.

Personally, I am in favor of adding this. I am interested in hearing the thoughts of others though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant