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

[cueckoo]

Originally opened by @mpvl in cuelang/cue#388

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!

[cueckoo]

Original reply by @philipdexter in cuelang/cue#388 (comment)

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?).

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

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.

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

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).

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

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

[cueckoo]

Original reply by @philipdexter in cuelang/cue#388 (comment)

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.

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

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

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

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.

[cueckoo]

Original reply by @mpvl in cuelang/cue#388 (comment)

This is now in.