search

cbor-wg / edn-literal

Application-oriented literals for CBOR extended diagnostic notation
Other
0 stars 7 forks source link

Clarify: NaN representatioin #39

Closed chrysn closed 2 months ago

chrysn commented 2 months ago

As part of working on an implementation, I noted that NaN payloads are not expressible -- a diag2cbor can take NaN to mean F9 7E00, but if I find F9 7E01 I can't express this in EDN without losing information.

I think that's OK because NaN payloads are a niche case, and because there is the extension point of specifying a nan'7e00' literal (with the caveat that while most other literals can be turned into a non-application-literal form, this one can't, so EDN libraries may need to support it internally rather than through an extension point). Still would like to confirm that this is an intentional elision.

cabo commented 2 months ago

It is slightly weird that app-string resolvers that implement nan'...' will need to output non-basic EDN, but otherwise I'm fine with leaving this to an app-extension -- I'd rather have a use case in hand for which we design this. (The syntax clash between NaN and nan'foo' worries me slightly in case we ever get rid of required commas, but that has to be solved there.)

chrysn commented 2 months ago

Thanks, then let's close this.

The weirdness of producing non-basic EDN is a tad odd, but given that implementers may choose to also treat h, b64 & co as application oriented literals, they may already be familiar with the situation, because other than through those they can't produce non-UTF8 binary strings.