You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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:
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
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.
The text was updated successfully, but these errors were encountered:
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):
And now we can do things like this:
And then there are other modules like
Data.Primitive.ByteArray.LittleEndian
that illustrate what can be done with just theBytes
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:
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.
The text was updated successfully, but these errors were encountered: