Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is "keyable"? #43

Open
kengruven opened this issue Jul 26, 2023 · 4 comments
Open

What is "keyable"? #43

kengruven opened this issue Jul 26, 2023 · 4 comments

Comments

@kengruven
Copy link

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?
@ST92
Copy link

ST92 commented Aug 1, 2023

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!

@kstenerud
Copy link
Owner

kstenerud commented Aug 10, 2023

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...

@kengruven
Copy link
Author

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. :-)

@kstenerud
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants