Re: [Cbor] Reminder and call for agenda: CBOR WG Virtual Meeting on 2022-06-01

[Carsten Bormann <[e-mail]>]

Hi Christian,

thank you for this quick feedback!

> 
>> When reconstructing the original data item, such a reference is
>> replaced by a data item constructed from the argument data item found
>> in the table (argument, which might need to be recursively unpacked
>> first) and the rump data item (rump, again possibly recursively
>> unpacked).
> 
> This reads a bit like also the rump would be recursively unpacked first.
> Is that the intention? (I think not -- with my understanding of
> unpacking so far, the rump would be unpacked at the time it is
> encountered in the reconstructed item, allowing the argument to alter
> the dictionary).

You lost me at “alter the dictionary”.

The argument *is* in the dictionary.
The rump needs to be “recursively” (we need to fix this term) unpacked because any parameters to the function tag (or to the affixing process) need to be unpacked (conceptually!) before they are applied.
In a real implementation, the unpacking could be done by a visiting accessor, so there is no actual recursion.

>> [...]; a type-0 reference is either a prefix reference or a
>> type-0 function reference, while a type-1 reference is either a
>> suffix reference or a type-1 function reference.
> 
> I find the type-0/type-1/"dominating tag" concept rather hard to
> understand. It's neat how it allows symmetry between reference and
> argument (which is especially pronounced when prefix/suffix becomes
> concatenation),

Yes!

> but I'm unconvinced that that symmetry is worth the
> cognitive / implementation load of doing it that way,

It makes sense to point out on which end the function tag is (we found good examples for both ends).  Of course, we could just take the end which has a tag, but that makes things a bit less deterministic (and becomes complicated if both ends have one).  I’d rather be explicit on where the function tag is, and the same bit that decides prefix vs. suffix can also be used to decide argument-tag vs. rump-tag.  The “type-0”/“type-1” wording is scary for about 20 minutes :-)

> or even generally
> present. (One can always swap the arguments of a two-argument function,
> but not for all functions either argument makes sense in a dictionary).

Sorry, I have been using “argument” for the thing looked up in the table, so we only have one argument (that goes into one of the two parameters of the tag function :-).  Maybe we need a better word than argument.

> Alternatives I'd like to suggest for consideration:
> 
> * Maybe the mechanism described in the branch can be explained in an
>  easier-to-digest way. It may or may not become simpler by either of
> 
>  * giving names to the two arguments the of the function (arg1, arg2?
>    A, B? tagged, other?)

Left hand side, right hand side.

>  * calling prefix/suffix just "concatenation" (arg1 | arg2) and not
>    treating it as an extra case but as the default

Yes, that might help.

> * Use a bit more separate tags for where there is real need for having
>  both directions. (No type-0/type-1 distinction, and having the
>  tag-that-indicates-function always in the dictionary. For string/array
>  postfixes that'd need a tag already at dictionary setup).

I need an example.

"having the tag-that-indicates-function always in the dictionary.” Has the disadvantage that you cannot use the same table entry string for midfix-from-rump and affix, as in my example.

> * Decoupling the functions a bit more from the compression, and using a
>  more general mechanism to fill them.
> 
>  There might not be much point in having `109(["example.com",
>  ["https://", "/foo".html"]])` around explicitly in any document, but
>  in a generalization the tag could mean "string-join arg2 with arg1",
>  and all of a sudden `109([",", ["1", "2", "3"]])` or even `109([",",
>  64('123')])` could be usable more generally even outside packing.

Nice! s/midfix/join/… then (106 ‘j' is not taken yet :-)

join(“.”, [“datatracker”, “ietf”, “org”])…

>  In packing, they'd be used as
> 
>  ```
>  113([[],
>    [109(["packed.example", ARG])],
>    [6(["https://", "/foo.html"]),
>     ...
>    ]
>  ])
>  ```

What is ARG?

>  or (in the other example's style)
> 
>  ```
>  113([["packed.example"],
>    [],
>    [109([6(0), ["https://", "/foo.html"]]),
>     ...
>    ]
>  ])
>  ```

I’m not yet quite ready to embrace general function evaluation as a part of CBOR (outside unpacking, that is).

>  (The first example here does beg the question the 'put the argument in
>  here' placeholder ARG is best phrased; I don't have any definite
>  answer here yet, but maybe it makes sense to shift up the index space
>  inside the argument-item space by 1 and make 6(0) the argument --
>  although that might be similarly hard to teach as type-0/type-1.)

The current design clearly identifies function tags as such by using them as lhs (from a type-0 reference) or rhs (from a type-1 reference) of an argument reference.  We need a way to be able to identify them because:

— Not every processor can know every function tag in existence, so we need to know when a function tag is actually “invoked” to find ones that we don’t know
— A function tag might be used in its meaning as a mere tag, i.e., not automatically evaluating.

Grüße, Carsten


> 
> BR
> Christian
> 
> who is wondering whether indefinite-length strings / bytestrings really
> needed to be in the original CBOR spec, or would not have been better
> served with a "concatenate" tag around an indefinite-length array.

Knowing after almost a decade how we have learned to use tags, this could indeed be done differently…

Grüße, Carsten