RFC: how to map oddly named definitions in JSON Schema to CUE

[mpvl]

The new definition syntax moves definitions to a different namespace from regular fields. This property allows us to map JSON Schema fields and definitions within the same struct, resulting in clean mappings.

However, the new syntax now requires that definition names be valid identifiers. This means that a JSON Schema definition named "working-directory" cannot be mapped directly to a definition in CUE. Currently, the workaround is to map such oddly named definitions to a special map:

#def: "working-directory": { ... }

This allows referring to this definition as #def."working-directory". A disadvantage of this approach is that a definition named "def" now also needs to be moved into this map.

A small language change, allowing # as an identifier, would allow the following mapping:

#: "working-directory": { ... }

which allows referring to this as #."working-directory".

Pros:

• shorter
• avoids having to special case a definition named def
• more reflects that the reason for this is special

Cons:

• looks odd and special
• requires a language change, although minor (allow # to be a valid identifier)
• allowing # as an identifier may have consequences down the line

We are considering to eventually allow #(x): y and a.#(x) for dynamic definitions labels, analogous to (x): y and a.(x) as proposed in the Query Proposal #165. We could say that the use of #: "x": y will be translated to #("x"): y once this feature becomes available. This is less tenable when the mapping is #def.

Thoughts welcome!

[philipdexter]

My initial reaction was that #: and #. looked too much like magic/special syntax. But it only takes one encounter to remove the magic. The benefits outweigh the cons, in my opinion (though it's hard to put a weight on "allowing # as an identifier may have consequences down the line", any insight into into what consequences there could be?).

[mpvl]

For instance, consider the #(x) syntax, also mentioned above. The most simple and obvious way to interpret that, syntactically, is as a CallExpr. This means that # is an identifier there too, but this time a builtin. Still not a problem for CUE, as builtins are just predeclared identifiers, but it may be confusing that # means something different based on the context. This will be mitigated if we say upfront that # will be rewritten anyway to this alternative.

[mpvl]

Even if we leave both options and accept that the # builtin can be shadowed (like any other builtin), there is still the question how such a map would interact with a possible type cast or interpret-a-struct-as-function shorthand syntax. Most notably, if we accept that # is an identifier, we have less flexibility in syntactically interpreting #(x).

[mpvl]

But these consequences are mitigated if we indicate clearly (somehow) that # may map to #(x) in the future.

[philipdexter]

I see. That's a good point. If somebody shadows # and then writes #(x) then they will most likely be confused by the output. But if they use/shadow # to begin with then chances are they are aware of the semantics.

[mpvl]

Yeah, I think it is not really an objection given all the possibilities.

[mpvl]

BTW, as we don't have the a."foo" notation yet, for now a lookup would have to written as #["foo"]. This can be trivially rewritten automatically to a nicer form later.

[mpvl]

This is now in.

[cueckoo]

This discussion has been migrated to cue-lang/cue#388.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.