Re: [Cbor] A CBOR tag for alternatives/unions, request for comments

[Michael Peyton Jones <[e-mail]>]

> Does it, for the applications expecting to use this, make a noticable
difference whether a 1+1 or a 1+2 tag is used?

This is a great question.

> The difference is likely most pronounced on alternatives without actual
payload

More generally, the tag overhead is important in cases where the space used
for tags is significant relative to the space used for the payloads. The
case where there is no payload is one example.

Another example that's interesting is where there is a lot of *structure*
to the data. If you'll permit me a toy example, suppose we have a balanced
binary tree of numbers. In Haskell, the data type definition would look
like this:

data Tree = Leaf Int | Node Tree Tree

If we encode such a structure using the proposed alternative tags ('0' for
'Leaf' and '1' for 'Node') then we will have 2n-1 nodes for n entries in
the tree, and hence that many tags. If the entries themselves are not
enormous, then the proportion of the total space usage devoted to the tags
can become significant! We have encountered this problem in real life.

Putting it another way: some tags are useful, but occur infrequently. There
is little point in optimizing their space usage. However, we expect that
the users who *do* use these tags will use them a *lot*, and so optimizing
them provides a decent benefit.

Best wishes,
Michael

On Thu, 24 Feb 2022 at 13:48, Carsten Bormann <[e-mail]> wrote:

> > […] this is not a case coming
> > from the constrained or high-volume applications that CBOR was designed
> > for, […]
>
> I’m not so sure about the constrained space:
> Rust has a strong ascent as the language of choice in the constrained
> space.
> Rust also has a strong enum system.
>
> (Rust is also of interest in the high-volume space.)
>
> Grüße, Carsten
>
>

-- 

*Michael Peyton Jones*
Software Engineering Lead | London, UK

Website: www.iohk.io <http://iohk.io>
Skype: michael.s.pj
Twitter: @mpeytonjones
PGP Key ID: 29F64616

[image: Input Output] <http://iohk.io>

[image: Twitter] <https://twitter.com/InputOutputHK> [image: Github]
<https://github.com/input-output-hk> [image: LinkedIn]
<https://www.linkedin.com/company/input-output-global>


This e-mail and any file transmitted with it are confidential and intended
solely for the use of the recipient(s) to whom it is addressed.
Dissemination, distribution, and/or copying of the transmission by anyone
other than the intended recipient(s) is prohibited. If you have received
this transmission in error please notify IOHK immediately and delete it
from your system. E-mail transmissions cannot be guaranteed to be secure or
error free. We do not accept liability for any loss, damage, or error
arising from this transmission