I have a moderate sized Elm application that deals with binary protocols (specifically SysEx data dumps and messages that MIDI instruments send). Back in 0.18, I wrote my own
ByteArray type, and associated parser, builder, and codec style combinator libraries.
I’ve moved the app to 0.19, and am starting to replace my functionality with
First thing I’ve run into is that
Byte.Encoder objects can’t fail to encode. A reality of many “bytes on the wire” protocols is that the logical Elm types that they decode into, can have values that can’t be correctly re-encoded. This happens commonly in two cases:
Fields that have limited valid ranges: For example, it might encode a value as a 16bit integer, but perhaps only values between 0 and 4,000 are legal. If it is decoding into an
Int, then corresponding encoder has no way of signaling failure if encoding a value outside the range.
Repeated structures: For example, a data dump might have exactly 80 copies of some other structure in a row. It would be best to decode that into
[Thing]– and it is easy to make the decoder decode exactly 80… But the encoder has no way of signaling failure if the passed array or list value is the wrong size.
Now, you might argue that these kinds of constraints should be checked - like other structural constraints - before passing to the
Encoder. But if you are building up the encoder from parts - you’d have to replicate the whole structure again building up a checker. It generally makes sense - esp. for these low level field checks or simple structural checks - to build them up as you are building the encoder.
I think I might be able to build a “checked” encoder API on top of the existing one… but I thought this observation might be interesting to discuss.