Consider an encoding profile system

[io7m]

Currently, CCBE is the only defined encoding for Cedarbridge. Although it is an efficient encoding in that it transfers absolutely no type information whatsoever, it does have a bit of waste in the sense that string and sequence lengths are always 32-bit integers, and variant indices are also always 32-bit integers. The utter simplicity is a desirable property and should be preserved and left as the default. However, this doesn't mean that it shouldn't be possible to introduce new alternative encodings if two peers can communicate this encoding out-of-band.

For many protocols, 16-bit integers might be enough for strings and sequences, and 8-bit integers might be enough for variant indices.

However, the Cedarbridge compiler has no way to know which encoding is going to be used and so it can't perform checks that might be useful. For example, if there's a hypothetical mini8 encoding that encodes all lengths and indices as 8-bit integers, then the compiler should check that variants and protocols don't contain more than 255 cases/messages. This could be achieved with an encoding declaration:

[encoding mini8]

... Where the default if no encoding is specified is:

[encoding canonical]

[io7m]

The first step would be to change the signature of readVariantIndex and writeVariantIndex. The methods should take an integer constant parameter specifying the maximum index value so that the underlying serializer can intelligently size the value to be read/written if it wants to. The default serialization context would continue to unconditionally write a 32-bit integer as usual.

[io7m]

By this, for example, I mean that if a call writeVariantIndex(230) is made, the implementation can say "we're writing a value of a variant that has 230 cases, therefore the variant index can fit in an 8-bit unsigned integer".

[io7m]

I think the encoding statement should be available to specified multiple times. Each statement indicates to the compiler that it needs to check if all of the type and protocol declarations are compatible with the given encoding. If no encoding statement is present, then [encoding canonical] is assumed.

An unsolved issue: What if a package that supports [encoding mini8] imports a package that doesn't support it? What if the imported package doesn't explicitly say it supports any particular protocol?

If the encoding checks are implemented on the typed AST returned by the module loader, then this isn't a problem: The compiler can check the transitive closure of the current module against all encoding statements given in the current module.