Byte order

[lassik]

Endianness is often easiest to specify once for the entire record, but there may be cases where it needs to be per-field. So let's have a default endianness for each record type and allow an optional override for each field.

Sometimes the same record can be stored bi-endian depending on the underlying CPU or whether the date is on disk or in RAM, etc. So the record type's endianness should be advisory, and users of the type should be able to override it if desired. This also means that we should let people define record types with no advisory endianness, in which case the user of the type is required to pass in the endianness each time.

If the user overrides the record type's endianness, and some fields override it as well, what should happen to those fields? If record R is little-endian but its field F is big-endian, and the user wants a big-endian version of R, should F be flipped into little-endian in that version, or should it stay big-endian?

[johnwcowan]

Rather than overrides, overrides on overrides, etc., just specify it the way that (rnrs bytevectors) does: u16 means native, u16-be means big-endian, u16-le means little-endian. It's compact enough.

[lassik]

Well designed file formats and protocols use a fixed endianness. Hence defaulting to native-endian is a bad idea.

Endian overrides (or swaps) are necessary since some formats are bi-endian. It doesn't make sense to specify the same record types twice, with no other differences besides endianness.