Remove backtick literals

[innovate-invent]

@springcomp suggested adding support to the grammar for unquoted number literals: 3.2 vs `3.2`.

This may be a good idea, but we need to consider the consequences.
With unquoted number literals, raw-string literals, multi-select-hash, and multi-select-list, what would be the remaining purpose of literal in the grammar? true, false, and null only?

Additionally, this may also conflict with the possibility of allowing numeric identifiers:
Given {"foo":{"1":"a"}} it would be consistent and convenient to allow for the path foo.1 or foo | 1 to access the value 'a'.
I recently encountered a desire for this behaviour and had to opt for foo."1" with the current grammar.

I think there would be real value to completely remove literal from the grammar. Making true, false, and null unquoted values.
true, false, and null are unlikely to occur as identifiers and we can fall back to quoted-strings in the event that they do occur.

[springcomp]

I think we can not drop literals completely, because that would lead to conflicts.
For instance, consider the two following expressions:

{a: {b: c}}
{a: `{"b": "c"}`}

The first first is a multi-select hash where the value for the key a is also a multi-select hash.
The second expression is also a multi-select hash with a key a, however, the value for key a is a static JSON object.

Droping literals would not allow to express the second expression.

[innovate-invent]

I think the competing syntax's would be:

{a: {b: 'c'}}
{a: `{"b": "c"}`}

These would produce the same values.

[springcomp]

Oh, indeed you are right.

So dropping literal-expressions is definitely technically possible, provided we introduce true, false and null as special terminals in the grammar. Now the question remains as to whether this brings enough value to warrant breaking compatibility in such a way.

[innovate-invent]

I think this should be done packaged along with the other backwards compatibility breaking changes I have proposed.

[springcomp]

Additionally, this may also conflict with the possibility of allowing numeric identifiers:
Given {"foo":{"1":"a"}} it would be consistent and convenient to allow for the path foo.1 or foo | 1to access the value 'a'.
I recently encountered a desire for this behaviour and had to opt for foo."1" with the current grammar.

For reference, let me include a reference to JEP 6 that explicitly explains the rationale against supporting numeric identifiers.

[innovate-invent]

Thanks, that pretty much confirms this then. JEP-6 looks like it was intended to pave the way to allow for un-backtick-quoted number literals.