cmd/cue: no error in presence of apparently empty list passed to or builtin

[myitcv]

What version of CUE are you using (cue version)?

$ cue version
cue version +304b02e linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

Consider first x.cue:

-- x.cue --
package x

#Guide: {
        Terminals: [string]: #Terminal

        Steps: [string]: #Step
}

#TerminalName: or( [ for k, _ in #Guide.Terminals {k}])

#Step: {
        Terminal: #TerminalName
        Cmd:      string
}

#Terminal: {
        Image: string
}

g: #Guide & {
        Terminals: t1: Image: "golang"

        Steps: ls: #Step & {
                Terminal: "t2"
                Cmd:      "ls"
        }
}

cue eval -c x.cue gives no error, despite the fact that "t2" references a non-existent terminal.

If instead we move the definitions of #Step et al inside #Guide:

-- y.cue --
package x

#Guide: {
        Terminals: [string]: #Terminal

        Steps: [string]: #Step

        #TerminalName: or( [ for k, _ in Terminals {k}])

        #Step: {
                Terminal: #TerminalName
                Cmd:      string
        }

        #Terminal: {
                Image: string
        }
}

g: #Guide & {
        Terminals: t1: Image: "golang"

        Steps: ls: #Guide.#Step & {
                Terminal: "t2"
                Cmd:      "ls"
        }
}

Then cue eval -c y.cue gives:

g.Steps.ls.Terminal: empty disjunction

I suspect the poor error message is to be expected in this release. But at least in this case the error is caught (changing "t2" to "t1" fixes the problem).

Not nesting the definitions (the approach in x.cue) feels "wrong" but I can't articulate why. In any case, it feels like there should be an error of some sort in that case because I assume from the lack of error relating to the fact that "t2" is not in the list ["t1"] then the list must be empty. But this should result in an error because or cannot be passed an empty list AFAIK.

Apologies if the language above is a bit loose, but hopefully I've managed to convey the gist of my understanding/the problem.

[mpvl]

Not nesting the definitions is wrong, because subsequently using them in g will not cause fields within them to automagically resolve to the respective fields within g. So #Guide.Terminals in #TerminalName, for instance, will always resolve to an empty set.

[mpvl]

The problem with or is an interesting one. Right now it returns an "incomplete" error. But returning an evaluation error would cause the evaluation to fail prematurely. The "t2" should still not unify with an incomplete error, though.

On the other hand, if it returns a disjunction, and it is unified with a concrete value, then down the line if a definition is used somewhere where the comprehension source is expanded, even there a unification failure may be (correctly) turned into a correct value.

This seems to indicate that a failure within a definition should not be terminal for the entire configuration, or that there can also be "open" disjunctions.

[myitcv]

Not nesting the definitions is wrong, because subsequently using them in g will not cause fields within them to automagically resolve to the respective fields within g

Indeed, which is exactly what my intuition tells me, but as I mentioned above I can't honestly say that I could point (someone) to a precise explanation in the spec that articulates this. Where would you refer someone on this point?

Thanks for the explanation on the or point.

[mpvl]

It can be derived from the spec, but it is not obvious. There really should be a language guide and/or something like "Effective CUE".

[myitcv]

There really should be a language guide and/or something like "Effective CUE".

Completely agree. I just wondered whether this should actually be made more obvious from the spec, but I definitely defer on that point!

[mpvl]

Closed due to typo. Reopening.

[mpvl]

Consider also

// example.cue
subject: {
	keys: [for k,s in states {k}]
	initial: or(keys)
	states: [K=string]: {
		key: K
	}
}

rejects: {
	initial: "blue"
	states: "red": {}
	states: "green": {}
}

passes: (subject & rejects) == _|_

See #601

[cueckoo]

This issue has been migrated to cue-lang/cue#475.

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