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

[gogommartin]

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"
    }]
}

[myitcv]

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

[seh]

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.

[mpvl]

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.

[mpvl]

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.

[seh]

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.

[cueckoo]

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

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