concise-encoding icon indicating copy to clipboard operation
concise-encoding copied to clipboard

What is "keyable"?

Open kengruven opened this issue 2 years ago • 4 comments

The spec defines keyable types, but the spec is not consistent with the reference implementation, and not even internally consistent.

  1. Are booleans "keyable"? They're not in the list, but they are in the grammar.
  2. The spec says -0 is not allowed (though -0 is defined as a floating-point value, so this rule seems redundant), but enctool allows it, e.g., {0=1 -0=2}.
  3. I don't see anything in the spec about key equivalence across types, but it seems to be an error in the reference implementation to have both a temporal type and a similar string, e.g., {2001-01-01=1 "2001-01-01"=2} or {00:00:00=1 "00:00:00"=2} are errors but {1=1 "1"=2 @"1"=3} is valid. Is this a bug, or is it intended that temporal types (only) can't live next to strings?

kengruven avatar Jul 26 '23 16:07 kengruven

Hi!

  1. Booleans are equivalent enough to one bit int it's taken as implicit. It's beyond the scope of the spec.
  2. -0 is not allowed rule comes from a conscious effort to reduce ambiguity and (even more from) some machine platforms (aka processor architectures) actually don't support -0 in this context.
  3. I'm not sure about how to deal with this one

These are all good questions!

ST92 avatar Aug 01 '23 18:08 ST92

Hi sorry,

1 booleans are supposed to be keyable (but not equivalent to any integer). I'll add that in.

  1. -0 is not allowed as a key even though the binary format allows encoding -0 as an "integer" due to how the encoding format works.

  2. I'm not sure what you mean by this... strings are never equivalent to non-strings (there's no way to automatically infer whether they represent the same thing or not). Strings can only be compared to strings, time can only be compared to time, boolean only to boolean, etc. The only types that should be cross-comparable are numbers (integers and floats). Although now that I think of it, the reference implementation may be incorrectly comparing equal for resource ids and remote refs...

kstenerud avatar Aug 10 '23 06:08 kstenerud

Part 1 looks like an easy fix in the spec -- thanks.

Parts 2 and 3 look like implementation bugs, correct? Would you like me to file separate issues for those?

Follow-up: the CE spec says "Integer values CAN be positive or negative". As zero is neither, it's not technically a valid integer in CE. :-)

kengruven avatar Aug 10 '23 18:08 kengruven

2 and 3 are bugs, yes.

"Integer" is a problematic word because it has one meaning in the mathematical sense (without 0) and another in the programming language sense (with 0). I think I put a minor treatise on it somewhere in the spec... Or maybe that was the Dogma spec? I'll have to look and see about clearing it up.

kstenerud avatar Aug 11 '23 04:08 kstenerud