Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#412 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
haskell
Domain
backend

Research direction

Read the referenced issue 409 and the existing Data.Primitive.ByteArray.LittleEndian module, then review the proposed ByteOrder, Fixed, FixedOrdering, and Bytes interfaces alongside the GHC primops mentioned here. A useful outcome is a documented decision about which functionality belongs in primitive and what API scope would be required.

Written by the indexing model from the issue text.

Description

In https://github.com/haskell/primitive/issues/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.

Dominant language
Haskell
Stars
123
Forks
60
Avg merge
14d 14h
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from haskell/primitive

All issues in haskell/primitive

Similar issues

More Haskell issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.