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

Christian Amsüss <christian@amsuess.com> Wed, 20 April 2022 15:18 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA03A0B1C; Wed, 20 Apr 2022 08:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RScu2XpbGj_O; Wed, 20 Apr 2022 08:18:46 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76CA3A0C36; Wed, 20 Apr 2022 08:18:05 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 23KFI1WE042438 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Apr 2022 17:18:02 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4EB8FD0; Wed, 20 Apr 2022 17:18:01 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:f4a1:2988:1247:a691]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id E9F21FD; Wed, 20 Apr 2022 17:18:00 +0200 (CEST)
Received: (nullmailer pid 636774 invoked by uid 1000); Wed, 20 Apr 2022 15:18:00 -0000
Date: Wed, 20 Apr 2022 17:18:00 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Michael Peyton Jones <michael.peyton-jones=40iohk.io@dmarc.ietf.org>
Cc: Carsten Bormann <cabo@tzi.org>, Duncan Coutts <duncan@well-typed.com>, Alexander Byaly <alexander.byaly@iohk.io>, Jared Corduan <jared.corduan@iohk.io>, cbor@ietf.org
Message-ID: <YmAkKEkRMtVFGiTU@hephaistos.amsuess.com>
References: <2BBF6463-FDB2-4A8A-B20D-7A1AD976A90D@tzi.org> <CAKoRMYFi8uo2GfHA9s1n+-rMO8Ja9=2qMMzjS9Z=F9r3LFozRQ@mail.gmail.com> <8EA89504-C176-4850-9BB8-C7E7206374FF@tzi.org> <CAKoRMYGmOa0hzEFsJh8kpz0bU5x56Yc9P=DBK-ghU83gXxPv7A@mail.gmail.com> <CAKoRMYGUvmxufQUVyvX2mciq5LCmV0Nz-uE2MJn54GDBB+9DRw@mail.gmail.com> <CAKoRMYF_19V6mu4S9GVqfiNzyQVvvOzX6eYwHp_DtZQoG0xTKg@mail.gmail.com> <4B47F4D7-ADE3-4A22-8A5B-97F4E5FCD933@tzi.org> <Yhd3/bwVUOLJLzWu@hephaistos.amsuess.com> <B6FC521C-1C28-4B11-90F2-DE62308B7168@tzi.org> <CAKoRMYGVii8eQAPsGWJn-H8+kJ81QkOGWpybDK44b5wsJbjxtw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="0TWMXxEqKW+pNiod"
Content-Disposition: inline
In-Reply-To: <CAKoRMYGVii8eQAPsGWJn-H8+kJ81QkOGWpybDK44b5wsJbjxtw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/H5UJC4O23728UZhobZ23BFoBoJE>
Subject: Re: [Cbor] A CBOR tag for alternatives/unions, request for comments
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Apr 2022 15:18:49 -0000

Hello Michael, Carsten,

On Thu, Feb 24, 2022 at 02:12:43PM +0000, Michael Peyton Jones wrote:
> 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:

Right, multiply tagged items are something I did not consider
originally. (My mental model for these was shaped by Rust where there is
often type information available, so that an Option<Option<Option<u8>>>
has all the information available to still fit in 16 bit, but that's of
course only available on types that are just repetitive and not
recursive).

I'd still be slightly happier if this would take less of the 1+1 space
(121 and 122, maybe? That would suffice for the deep parts of the tree),
but given it also has Carsten's support (who is the other expert for the
registry), I'd be OK with it.

The policy for registering these are "specification required", so it all
doesn't have to wait for notable-tags to be full and done -- and I'm
just about to send out another mail suggesting to use this. What's your
plan for progressing with this?

BR
Christian

-- 
There's always a more constrained fish.
  -- Qui-Gon Jinn