Re: [Json] Doofus Parameter Labels

[Nico Williams <[e-mail]>]

On Mon, Mar 30, 2015 at 03:38:39PM -0400, Phillip Hallam-Baker wrote:
> So, I am implementing an IETF draft which is fairly widely used and
> using a code generator to speed things along.
> 
> The code is breaking because the spec has decided to use 'protected'
> as a tag which is of course a reserved keyword in Java, C# and much
> else.
> 
> OK so there is an escape feature that I can use instead. But those
> don't exist in other languages. And then I come across a tag that has
> a non alphanumeric tag value.

This sort of question comes up a lot for jq.  I don't think you can
produce a generic rule here.  "protected" is a keyword in many
languages, but not others.  It's not a keyword in jq, for example,
though 'reduce' is (which is probably not a keyword elsewhere).

There is a workaround, of course.  Instead of writing

    .then.protected

one has to write

    .["then"].protected

or

    ."then".protected

in jq in order to access the value at the "protected" object name in the
object at the "then" name in the top-level object.

What sort of rule do you have in mind for avoiding this?  Why are the
workarounds insufficient?

> This sort of thing is likely to be happening quite a bit now that
> people are using JSON and it would be a lot better if we could avoid
> it. The fact that JSON allows tags to be any valid UNICODE sequence
> does not mean that all choices are equal.

There are other considerations too.  For example: names shorter than 8
or 16 bytes may get treated as immediate values, without heap allocation
(I have a half-baked patch to do that for jq) in some implementations.
(E.g., a NaN-coding implementation may be able to store most 7-byte
strings as immediate values.)

> In general it would be good if people writing specs could stick to the
> identifier naming rules for C and avoid reserved words from Java, C#,
> etc. The languages and tools I use are quite capable of using accented
> characters. I have absolutely no clue how to generate them on the
> keyboard though.

OK, so, stick to identifier naming rules for C, avoid keywords from some
set of programming languages, and don't use non-ASCII characters.  How
do we specify such constraints?  Remember, programming language specs
evolve and tend to grow new keywords.

-1