| cue eval types.cue |
| cmp stdout expect-stdout-cue |
| |
| -- frontmatter.toml -- |
| title = "Type Hierarchy" |
| |
| -- text.md -- |
| CUE defines the following type hierarchy |
| |
| ``` |
| null bool string bytes number struct list |
| / \ |
| int float |
| ``` |
| In addition, CUE defines the values |
| bottom, or error, (denoted `_|_`) |
| that is an instance of all types and |
| top, or any, (denoted `_`) of which all types are an instance. |
| |
| Note how we use the terms types and values interchangeably. |
| CUE does not distinguish between types and values. |
| The term "type" merely refers to the kind of a value, |
| which may or may not be a concrete instance. |
| |
| In the example, `point` defines an arbitrary point, while `xaxis` and `yaxis` |
| define the points on the respective lines. |
| We say that `point`, `xaxis`, and `yaxis` are incomplete, |
| as they do not specify a specific point. |
| Incomplete values cannot be represented as JSON, |
| as it can only represent concrete values. |
| |
| The only concrete point is `origin`. |
| The `origin` is defined to be both on the x-axis and y-axis, which means it |
| must be at `0, 0`. |
| Here we see constraints in action: |
| `origin` evalutes to `0, 0`, even though we did not specify its coordinates |
| explicitly. |
| |
| -- types.cue -- |
| point: { |
| x: number |
| y: number |
| } |
| |
| xaxis: point |
| xaxis: y: 0 |
| |
| yaxis: point |
| yaxis: x: 0 |
| |
| origin: xaxis & yaxis |
| |
| -- expect-stdout-cue -- |
| point: { |
| x: number |
| y: number |
| } |
| xaxis: { |
| x: number |
| y: 0 |
| } |
| yaxis: { |
| x: 0 |
| y: number |
| } |
| origin: { |
| x: 0 |
| y: 0 |
| } |