Is there a better way to inject a default list value than what I've come up with so far?

[cueckoo]

Originally opened by @gogommartin in cuelang/cue#399

Hi! 👋

I'm looking for a way to specify a list value that always contains a default value in descendant lists. I've found 2 ways that work, but they both feel cumbersome as the author of the descendant list has to be aware of the default value and explicitly include it for it to work properly. In the example below, is there a way to make option "d" work?

$ cat test.cue
_a: {
  a_list_with_a_default_value: [{foo: "bar"}, ...]
}

// works
b: _a & {
  a_list_with_a_default_value: [{}, {foo: "baz"}]
}

// works
c: _a & {
  a_list_with_a_default_value: _a.a_list_with_a_default_value + [{foo: "baz"}]
}

// fails, but this is the syntax I wish worked
d: _a & {
  a_list_with_a_default_value: [{foo: "baz"}]
}

$ cue eval -i test.cue
_a: {
    a_list_with_a_default_value: [{
        foo: "bar"
    }]
}
b: {
    a_list_with_a_default_value: [{
        foo: "bar"
    }, {
        foo: "baz"
    }]
}
c: {
    a_list_with_a_default_value: [{
        foo: "bar"
    }, {
        foo: "baz"
    }]
}
d: {
    a_list_with_a_default_value: [{
        foo: _|_ // conflicting values "bar" and "baz"
    }]
}

[cueckoo]

Original reply by @myitcv in cuelang/cue#399 (comment)

Probably the simplest way to do this for now is as follows:

package x

#a: {
	#vals: [...{foo: string}]
	res: [{foo: "bar"}] + #vals
}

b: (#a & {#vals: [{foo: "baz"}]}).res

This has the added advantage that when CUE supports embedded scalars the res field can be dropped and this example would become:

package x

#a: {
	#vals: [...{foo: string}]
	[{foo: "bar"}] + #vals
}

b: #a & {#vals: [{foo: "baz"}]}

(with some variation because the concatenation of lists might well change to be defined in terms of list comprehensions).

[cueckoo]

Original reply by @seh in cuelang/cue#399 (comment)

This is the first I've heard of this embedded scalars idea, and now I'm hungry for it. It's the closest thing to function-calls-as-expressions that I've seen proposed. #339 only mentions it obliquely, without showing off what would be possible.

[cueckoo]

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

Another idea we have been floating is to allow definition identifiers of the form #<num>, like #0 to indicate inputs. So given a struct, and combined with embedded scalars, one could write:

concat: {
  #0: string
  #1: string
  
  #0 + #1
}

and then write concat("a", "b") to obtain "ab".

Keep in mind, though, that the intention is still to disallow reentrancy, so such a "function" would not be able to call itself either directly or indirectly.

We still need to investigate how this syntax interacts with the need for type cases and some other ideas. But this seems nice. It would allow for functions without having most of the drawbacks of having functions.

[cueckoo]

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

In order to be able to do this, identifiers of the form #0 have been banned (for now) so that this can later be introduced without causing incompatibilities.

[cueckoo]

Original reply by @seh in cuelang/cue#399 (comment)

the intention is still to disallow reentrancy, so such a "function" would not be able to call itself either directly or indirectly.

Could one "function" call another "function"? You were careful to write "or indirectly," so if one function can call another, are you concerned only with cycles, or with calling depth? I take it that the concern is that such calls won't terminate, but it would be nice if there was some sort of "unsafe" annotation an author could attach that would promise that there is a base case for the recursion that's guaranteed to bottom out.