[RFC] base: Introduce GHC.ByteOrder
ClosedPublic

Authored by bgamari on Jul 24 2017, 10:12 AM.

Details

Summary

This provides a ByteOrder type as well as a targetByteOrder value, which
indicates the byte ordering used by the target machine. We might also consider
exposing this via Data.Bits if the CLC is so inclined.

Test Plan

Needs test

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
bgamari created this revision.Jul 24 2017, 10:12 AM
hvr awarded a token.Jul 24 2017, 10:17 AM
hvr accepted this revision.EditedJul 24 2017, 10:21 AM

Macro damngoodstuff:

PS: fwiw, I don't think Data.Bits is the place for this, as Data.Bits doesn't allow you to observe endianness afaik. However, Foreign.Storable is the API which lets you observe endianness.

This revision is now accepted and ready to land.Jul 24 2017, 10:21 AM
bgamari updated this revision to Diff 13310.Jul 24 2017, 10:22 AM

Add haddocks

RyanGlScott edited edge metadata.Jul 24 2017, 10:22 AM

This is really two different changes: the introduction of the ByteOrder data type, and the targetByteOrder function.

I suppose one might wish to export ByteOrder from Data.Bits, but since nothing in Data.Bits actually uses ByteOrder at the moment, I don't see much point in doing so.

targetByteOrder, on the other hand, is a system-specific implementation detail, so putting it in Data.Bits doesn't feel like the right decision. On the other hand, System.Info might be a somewhat natural home for this function, yes? I don't know for what purpose this is going to be used, but it might be more discoverable if it were to live there.

hvr added a comment.Jul 24 2017, 10:26 AM

@RyanGlScott IMO, the best place would be Foreign.Storable, as that's the API which lets you actually observe endianness.

RyanGlScott accepted this revision.Jul 24 2017, 10:28 AM

There are probably many good candidates for places to re-export ByteOrder from, but perhaps we should wait until we actually have another function(s) in base which makes use of it. For the time being, this PR looks fine as-is to me.

Sounds reasonable to me.

This revision was automatically updated to reflect the committed changes.