cmd/cue: vet: literal-only mode

[cueckoo]

Originally opened by @rogpeppe in cuelang/cue#130

Cue makes for a potentially nice representation format even just as a literal representation of the data, without any of the expressive power of identifiers, functions, definitions, etc.

As suggested by @crawshaw here, it might be good to have a literal-only vet mode (--literal ?).

Such a subset of cue would be more amenable to parsing by other languages that don't have the full cue machinery, while still providing a very readable syntax for config files and the like.

This could also be paired with a cue export type to render the output in Cue rather than JSON.

[cueckoo]

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

This is consistent with having a cue export mode type of CUE itself. That would be exactly that output.

Regarding the vet mode, I think the -c (concrete) option already does what you want. You may want to verify.

[cueckoo]

Original reply by @rogpeppe in cuelang/cue#130 (comment)

Regarding the vet mode, I think the -c (concrete) option already does what you want. You may want to verify.

That's a bit different. The -c option verifies that the output is concrete, but it still requires a full Cue interpreter to determine that concrete output. For example, cue vet -c succeeds on the following code:

import "strings"
x :: {
	y: strings.Join(["hello", "goodbye"], ",")
	...
}
z :: {
	z: 45
	...
}
w: x & z

So if you wanted to write a some code that reads the subset of cue accepted by cue vet -c, you'd have to implement all of cue, including the standard library. I'd like to see a format that really is just Cue literals, that could be implemented relatively straightforwardly in multiple languages and admits efficient and algorithmically simple runtime performance.

It could even have its own name - how about "Q (CUE) Strict Object Notation" or QSON for short?

[cueckoo]

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

@rogpeppe Cute how the S is repurposed as strict.

Fair enough. Should not be hard to implement. If a literal flag is set, one would walk over the ASTs of the parsed files (using ast.Walk) and verify there are only whitelisted nodes. I think just BasicLit, StructList, and ListLit, assuming you want to exclude BottomLit, and Ident in a Label position, comments, and the package clause. And probably attributes.

Another possibility is CUEL, but I agree it is helpful to look similar to JSON to express its familiarity.

Instead of --literal it code be a --mode=lit|graph|schema|all, which could also be used for export obviating the need for a separate gen command. See also #91.

Each output type could define the allowed modes. So for OpenAPI, there is only schema. For JSON there is only lit. For YAML it would be *lit|graph (I think). For Proto it would be lit|schema (I think, and default depends on extension, if specified). For CUE it would be lit|graph|schema|*all, where the default may vary based on the extension, if specified.

--mode could also be used for cue eval of course.

[cueckoo]

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

For vet we would need both a --mode and --inmode or something like that.

[cueckoo]

Original reply by @rogpeppe in cuelang/cue#130 (comment)

If a literal flag is set, one would walk over the ASTs of the parsed files (using ast.Walk) and verify there are only whitelisted nodes. I think just BasicLit, StructList, and ListLit, assuming you want to exclude BottomLit, and Ident in a Label position, comments, and the package clause. And probably attributes.

This was my initial take on that whitelisting, FWIW: https://play.golang.org/p/571l3JrXsaS