Support the empty symbol

[almann]

As per specification, the empty symbol is allowed, but not currently supported in the implementation.

Imported from ION-480

[SeanConnell]

Why is the spec this way? This seems like a step backwards from a "principle of least surprise" perspective and the current implementation's requirement of non-empty for symbols. Ion already has a problem with strangely equivalent types that are questionable (typed nulls) so why add fuel to the extant-but-empty party?

[tgregg]

Ion bills itself as a superset of JSON, and JSON allows empty keys.

[kenegozi]

IMO an empty string can be meaningful, an empty symbol not so much

[tgregg]

All field names (object keys in JSON) are symbols, not strings.

[SeanConnell]

@tgregg I assume you're referring to this line in the spec:

In the text format, structures are wrapped by curly braces, with a colon between each name and value, and a comma between the fields. For the purposes of JSON compatibility, it’s also legal to use strings for field names, but they are converted to symbol tokens by the parser.

Which means that we're stuck with the empty string turning into a symbol. That's a bummer, because it's arguably a nonsensical key to begin with. I guess to keep json support we're sort of stuck with it though.

[tgregg]

@SeanConnell Yep.

[toddjonker]

@kenegozi @SeanConnell Ion doesn't give any "meaning" to symbols distinct from strings, in fact it defines no meaning at all for symbols. By design, no Ion type defines any lower- or upper-bound on length. IMO uniformity between the types is less surprising than having only one type forbid zero-length sequences.

To say an empty symbol is "nonsensical" is to ascribe meaning that the specification very carefully avoids. If it's nonsensical to your application, then you are free to forbid them in your application. But at the serialization level we don't want to presume that we know what's meaningful to all applications.

@tgregg Let's be pedantic, in order to be clear: annotations and field names aren't symbols. They are their own things, with distinct (and different) syntactic rules in the text encoding. In the binary encoding they are encoded as symbol tokens, not symbols. The distinction is important because symbols are values, and values can have annotations and appear in containers, whereas symbol tokens cannot. Put another way, symbol tokens are part of the grammar, not the data model.

[kenegozi]

Thanks, that's a very sensible explanation.

…

On May 6, 2017 5:54 PM, "Todd V. Jonker" ***@***.***> wrote: @kenegozi <https://github.com/kenegozi> @SeanConnell <https://github.com/SeanConnell> Ion doesn't give any "meaning" to symbols distinct from strings, in fact it defines *no meaning at all* for symbols. By design, no Ion type defines any lower- or upper-bound on length. IMO uniformity between the types is less surprising than having only one type forbid zero-length sequences. To say an empty symbol is "nonsensical" is to ascribe meaning that the specification very carefully avoids. If it's nonsensical to your application, then you are free to forbid them *in your application*. But at the serialization level we don't want to presume that we know what's meaningful to all applications. @tgregg <https://github.com/tgregg> Let's be pedantic, in order to be clear: annotations and field names aren't symbols. They are their own things, with distinct (and different) syntactic rules in the text encoding. In the binary encoding they are encoded as *symbol tokens*, not symbols. The distinction is important because symbols are values, and values can have annotations and appear in containers, whereas symbol tokens cannot. Put another way, symbol tokens are part of the grammar, not the data model. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAQbrv1AdYwgGKP4i39FawmUOavXzC1ks5r3RYsgaJpZM4IJPfm> .