Cue language subsets

[ah-quant]

Cue could use defined subsets of the language for various use cases (a bit like json for JS).

Here, I'm talking about the language only.

If the need arises after 1.0, it will probably be quite hard to align the language with it, so having specs and considering them in design decisions should happen before.

I'm not sure about it, but I thought about some possible use cases yesterday and think the idea is compelling. I do not necessarily want all of them, but here are some profiles I thought about:

Self-sufficient: no module, no package, no import. Could be used for teaching or to encapsulate a library. When modules exist, it might be a compelling target format for cue export as a way to transfer a set of modules in a single file.

Simple: like above, but also without functions and _tool. This profile could be a compelling start for cue projects in other languages - writing parsers, writing alternative runtimes, experimenting with different evaluators or support tools. It lowers the barrier to entry and provides a set of functionality to standardize implementations and keep them comparable.

Config: like above, but no attributes, concrete values only, no optional or requires. Just json-like plus comments. More brevity than json but with the added comments. A very compelling alternative for yaml, less barbs and a lot of expressive power.

Json-like: like above but without comments. For direct translation, just for json simplification. Might be a requirement if there are no escaping requirements in comments, that could allow embedding in e.g. script tags. It's also a way to store json in a more compact form but support a lossless bidirectional transformation.

If any of these make sense, they should be defined early and considered in language extension decisions.

[mpvl]

I know all of these are answers at the tooling level, but:

The idea is to get rid of the special treatment of _tool.cue.

There are a few subsets of CUE defined already in the form of graph and data. See cue help filetypes.

CUE is a JSON superset, so JSON could be a considered a CUE variant as well.

The intent is for the cue def command to be able to create self-sufficient configurations.

I'm not sure to what extent having a version without builtin functions would work. The API is prepared to allow for the creation of CUE instances with user-defined possibly empty sets of builtins. This is not supported yet, though, as the consequences of this need to be considered more thoroughly.

[ah-quant]

cue help filetypes definitely goes in the direction I was thinking about - I missed it. But as you said, it's mostly addressing the tooling aspect.

Otherwise, I'd like to provide some context: I'm extremely fed up with the pervasive use of yaml as json with comments for configuration. Having a simple subset of cue there - reduced to only concrete values and without functions but still a json superset - will probably ease creations of parsing libraries. It can also - in additon to the spec - support a shared test corpus for implementations in various languages so it can act as a bridging configuration format - like yaml and json today.

Creating those libraries but also providing a runtime is too big a task, so I think functionality should be cut. And you and Paul should be able to concentrate on the "reference" implementation and general direction of cue. Alternative implementations would necessarily have to come from somebody else.

For that, it would need a separate and clear spec plus maybe a set of tests, but writing such libraries would be easier. And having a well specified profile would help. For embedding, you usually want a library in the language your system is written in. It also supports growth of the cue ecosystem from non-Go corners and will probably provide some more publicity.

This idea started brewing in me when I stumbled over e.g. https://github.com/tailscale/hujson

[ah-quant]

also, I'm just addressing the language here. Abilities to import various other formats (except json) and all the export functionality etc would not be part of this kind of reduced profile.

[mpvl]

Yes, the data-only representation is supposed to be exactly that. It may be an idea to split the test sets into cases for data- and/or graph-only tests.

Note that the graph representation also has a role here. It is not generally possible to represent YAML as JSON within linear bounded space. See https://en.wikipedia.org/wiki/Billion_laughs_attack. This format would still roughly conform to your requirements.

Using the graph representation, it is theoretically possible to convert YAML to CUE in bounded space. We plan to support this at some point. Together with structure sharing, this would allow such YAML files converted to CUE to be evaluated in bounded time. Graph unification + structure sharing can handle computation over infinite structure in bounded time. So this gives ways to work around such attacks, if the resulting CUE values are used with care (i.e. don't mindlessly walk over all values).

Getting to a stand-alone reference implementation is probably out of scope for now, but would indeed be interesting.
Our first attempt at supporting multiple languages will probably consist of cross-compiling to C libraries and JS/WASM, though.