cmd/cue: def roundtrip breaks for zero width bound

[antong]

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

$ cue version
cue version 0.4.0 windows/amd64

Does this issue reproduce with the latest release?

Yes, with v0.4.0.

What did you do?

$ cue def - <<EOF | cue def -
a: >=5 & <=5
b: a
b: float
EOF

What did you expect to see?

Not an error.

What did you see instead?

b: conflicting values 5 and float (mismatched types int and float):
    -:1:4
    -:2:8

The output of the first cue def is:

a: 5
b: a & float

I bumped into this when looking at #1310 . What I think goes on here is that >= 5 & <= 5 resolves to a concrete value of type number and magnitude 5 (both int 5 and float 5.0 are instances of this value). When exporting (cue def), value.Syntax() outputs this number as "5". This when taken as input is a literal 5 and is an int only (not a more general number,) so doesn't unify with float.

As far as I know there are only float and int literals, no way to directly specify a number literal. I guess the meaning of 5 | 5.0 would be close, but is that then that much better than >= 5 & <= 5.

For completeness sake, cue export :

$ cue export --out=cue - <<EOF
a: >=5 & <=5
b: a
b: float
EOF
a: 5
b: 5

and even

$ cue export --out=cue - <<EOF
a: >=5 & <=5
b: a
b: float & 5.0
EOF
a: 5
b: 5

[verdverm]

number is probably what you are looking for. It is essentially int | float

$ cue def - <<EOF | cue def -
a: >=5 & <=5
b: a
b: number
EOF
a: 5
b: a & number

This is where I am finding the inconsistencies for what various literal values are cast to. Sometimes it is a number other times it is the more specific int or float.

---

Note that the int version also works

$ cue def - <<EOF | cue def -
a: >=5 & <=5
b: a
b: int   
EOF
a: 5
b: a & int

[antong]

number is probably what you are looking for. It is essentially int | float

No, I'm sorry that I was unclear. I wanted to demonstrate the bug that when cue def exports >=5 & <= 5 (which unifies with float), then the CUE output is 5 (which doesn't unify with float). So information is lost and the output is more concrete than the input. The demo was to show how this can break stuff. The original CUE input is valid and can be exported. The output from cue def is no longer valid (unification error) and can't be exported, even though it should have identical meaning.

[myitcv]

So information is lost and the output is more concrete than the input

Agreed. This therefore looks like a bug to me.

Linking to #253.

[myitcv]

For completeness a txtar repro (tested against e8550b8):

exec cue def x.cue
stdin stdout
exec cue def -

-- x.cue --
a: >=5 & <=5
b: a
b: float

gives:

> exec cue def -
[stderr]
b: conflicting values 5 and float (mismatched types int and float):
    -:1:4
    -:2:8

[myitcv]

Noting also that we should ensure the spec examples mentioned in #1339 are accurate with respect to whatever we decide here.