-53

doc/tutorial/basics/0_intro/10_json.txtar

reviewed

··· 1 1 - exec cue export json.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "JSON Superset" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE is a superset of JSON. 10 10 - It adds the following conveniences: 11 11 - 12 12 - - C-style comments, 13 13 - - quotes may be omitted from field names without special characters, 14 14 - - commas at the end of fields are optional, 15 15 - - comma after last element in list is allowed, 16 16 - - outer curly braces are optional. 17 17 - 18 18 - <!-- 19 19 - {{< alert color="info">}} 20 20 - CUE borrows a trick from Go to make commas optional: 21 21 - the formal grammar still requires commas, 22 22 - but the scanner inserts commas according to a small set 23 23 - of simple rules. 24 24 - {{< /alert >}} 25 25 - --> 26 26 - 27 27 - JSON objects are called structs in CUE. 28 28 - An object member is called a field. 29 29 - 30 30 - -- json.cue -- 31 31 - one: 1 32 32 - two: 2 33 33 - 34 34 - // A field using quotes. 35 35 - "two-and-a-half": 2.5 36 36 - 37 37 - list: [ 38 38 - 1, 39 39 - 2, 40 40 - 3, 41 41 - ] 42 42 - 43 43 - -- expect-stdout-cue -- 44 44 - { 45 45 - "one": 1, 46 46 - "two": 2, 47 47 - "two-and-a-half": 2.5, 48 48 - "list": [ 49 49 - 1, 50 50 - 2, 51 51 - 3 52 52 - ] 53 53 - }

-51

doc/tutorial/basics/0_intro/20_cue.txtar

reviewed

··· 1 1 - 2 2 - -- frontmatter.toml -- 3 3 - title = "Types are values" 4 4 - description = "" 5 5 - 6 6 - -- text.md -- 7 7 - CUE merges the concepts of values and types. 8 8 - Below is a demonstration of this concept, 9 9 - showing respectively 10 10 - some data, a possible schema for this data, 11 11 - and something in between: a typical CUE constraint. 12 12 - 13 13 - {{< blocks/sidebyside >}} 14 14 - <div class="col"> 15 15 - <i>Data</i> 16 16 - {{< highlight go >}} 17 17 - moscow: { 18 18 - name: "Moscow" 19 19 - pop:   11.92M 20 20 - capital: true 21 21 - } 22 22 - {{< /highlight >}} 23 23 - </div> 24 24 - 25 25 - <div class="col"> 26 26 - <i>Schema</i> 27 27 - {{< highlight go >}} 28 28 - municipality: { 29 29 - name: string 30 30 - pop:   int 31 31 - capital: bool 32 32 - } 33 33 - {{< /highlight >}} 34 34 - </div> 35 35 - 36 36 - <div class="col"> 37 37 - <i>CUE</i> 38 38 - {{< highlight go >}} 39 39 - largeCapital: { 40 40 - name: string 41 41 - pop:   >5M 42 42 - capital: true 43 43 - } 44 44 - {{< /highlight >}} 45 45 - </div> 46 46 - {{< /blocks/sidebyside >}} 47 47 - 48 48 - In general, in CUE one starts with a broad definition of a schema, 49 49 - describing all possible instances, 50 50 - and then narrows down these definitions for particular use cases 51 51 - until a concrete data instance remains.

-34

doc/tutorial/basics/0_intro/30_duplicates.txtar

reviewed

··· 1 1 - exec cue eval dup.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Duplicate Fields" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE allows duplicated field definitions as long as they don't conflict. 10 10 - 11 11 - For values of basic types this means they must be equal. 12 12 - 13 13 - For structs, fields are merged and duplicated fields are handled recursively. 14 14 - 15 15 - For lists, all elements must match accordingly 16 16 - <!-- ([we discuss open-ended lists later](lists.md).) --> 17 17 - 18 18 - -- dup.cue -- 19 19 - a: 4 20 20 - a: 4 21 21 - 22 22 - s: { b: 2 } 23 23 - s: { c: 2 } 24 24 - 25 25 - l: [ 1, 2 ] 26 26 - l: [ 1, 2 ] 27 27 - 28 28 - -- expect-stdout-cue -- 29 29 - a: 4 30 30 - s: { 31 31 - b: 2 32 32 - c: 2 33 33 - } 34 34 - l: [1, 2]

-41

doc/tutorial/basics/0_intro/40_constraints.txtar

reviewed

··· 1 1 - exec cue eval check.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Constraints" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Constraints specify what values are allowed. 10 10 - To CUE they are just values like anything else, 11 11 - but conceptually they can be explained as something in between types and 12 12 - concrete values. 13 13 - 14 14 - But constraints can also reduce boilerplate. 15 15 - If a constraint defines a concrete value, there is no need 16 16 - to specify it in values to which this constraint applies. 17 17 - 18 18 - -- check.cue -- 19 19 - schema: { 20 20 - name: string 21 21 - age: int 22 22 - human: true // always true 23 23 - } 24 24 - 25 25 - viola: schema 26 26 - viola: { 27 27 - name: "Viola" 28 28 - age: 38 29 29 - } 30 30 - 31 31 - -- expect-stdout-cue -- 32 32 - schema: { 33 33 - name: string 34 34 - age: int 35 35 - human: true 36 36 - } 37 37 - viola: { 38 38 - name: "Viola" 39 39 - age: 38 40 40 - human: true 41 41 - }

-41

doc/tutorial/basics/0_intro/43_schema.txtar

reviewed

··· 1 1 - exec cue export schema.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Definitions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - In CUE, schemas are typically written as Definitions. 10 10 - A definition is a field which identifier starts with 11 11 - `#` or `_#`. 12 12 - This tells CUE that they are to be used for validation and should 13 13 - not be output as data; it is okay for them to remain unspecified. 14 14 - 15 15 - A definition also tells CUE the full set of allowed fields. 16 16 - In other words, definitions define "closed" structs. 17 17 - Including a `...` in struct keeps it open. 18 18 - 19 19 - -- schema.cue -- 20 20 - #Conn: { 21 21 - address: string 22 22 - port: int 23 23 - protocol: string 24 24 - // ... // uncomment this to allow any field 25 25 - } 26 26 - 27 27 - lossy: #Conn & { 28 28 - address: "1.2.3.4" 29 29 - port: 8888 30 30 - protocol: "udp" 31 31 - // foo: 2 // uncomment this to get an error 32 32 - } 33 33 - 34 34 - -- expect-stdout-cue -- 35 35 - { 36 36 - "lossy": { 37 37 - "address": "1.2.3.4", 38 38 - "port": 8888, 39 39 - "protocol": "udp" 40 40 - } 41 41 - }

-31

doc/tutorial/basics/0_intro/47_validation.txtar

reviewed

··· 1 1 - ! exec cue vet schema.cue data.yaml 2 2 - cmp stderr expect-stderr 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Validation" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Constraints can be used to validate values of concrete instances. 10 10 - They can be applied to CUE data, or directly to YAML or JSON. 11 11 - 12 12 - -- schema.cue -- 13 13 - #Language: { 14 14 - tag: string 15 15 - name: =~"^\\p{Lu}" // Must start with an uppercase letter. 16 16 - } 17 17 - languages: [...#Language] 18 18 - 19 19 - -- data.yaml -- 20 20 - languages: 21 21 - - tag: en 22 22 - name: English 23 23 - - tag: nl 24 24 - name: dutch 25 25 - - tag: no 26 26 - name: Norwegian 27 27 - 28 28 - -- expect-stderr -- 29 29 - languages.1.name: invalid value "dutch" (out of bound =~"^\\p{Lu}"): 30 30 - ./schema.cue:3:8 31 31 - ./data.yaml:5:11

-31

doc/tutorial/basics/0_intro/50_order.txtar

reviewed

··· 1 1 - exec cue eval -i order.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Order is irrelevant" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE's basic operations are defined in a way that the order in which 10 10 - you combine two configurations is irrelevant to the outcome. 11 11 - 12 12 - This is crucial property of CUE 13 13 - that makes it easy for humans _and_ machines to reason over values and 14 14 - makes advanced tooling and automation possible. 15 15 - 16 16 - -- order.cue -- 17 17 - a: {x: 1, y: int} 18 18 - a: {x: int, y: 2} 19 19 - 20 20 - b: {x: int, y: 2} 21 21 - b: {x: 1, y: int} 22 22 - 23 23 - -- expect-stdout-cue -- 24 24 - a: { 25 25 - x: 1 26 26 - y: 2 27 27 - } 28 28 - b: { 29 29 - x: 1 30 30 - y: 2 31 31 - }

-42

doc/tutorial/basics/0_intro/55_fold.txtar

reviewed

··· 1 1 - exec cue export fold.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Folding of Single-Field Structs" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - In JSON, one defines nested values, one value at a time. 10 10 - Another way to look at this is that a JSON configuration is a set of 11 11 - path-value pairs. 12 12 - 13 13 - In CUE one defines a set of paths to which to apply 14 14 - a concrete value or constraint all at once. 15 15 - Because of CUE's order independence, values get merged 16 16 - 17 17 - This example shows some path-value pairs, as well as 18 18 - a constraint that is applied to those to validate them. 19 19 - <!-- 20 20 - This also gives a handy shorthand for writing structs with single 21 21 - members. 22 22 - --> 23 23 - 24 24 - -- fold.cue -- 25 25 - // path-value pairs 26 26 - outer: middle1: inner: 3 27 27 - outer: middle2: inner: 7 28 28 - 29 29 - // collection-constraint pair 30 30 - outer: [string]: inner: int 31 31 - 32 32 - -- expect-stdout-cue -- 33 33 - { 34 34 - "outer": { 35 35 - "middle1": { 36 36 - "inner": 3 37 37 - }, 38 38 - "middle2": { 39 39 - "inner": 7 40 40 - } 41 41 - } 42 42 - }

-18

doc/tutorial/basics/0_intro/80_boilerplate.txtar

reviewed

··· 1 1 - 2 2 - -- frontmatter.toml -- 3 3 - title = "Boilerplate" 4 4 - description = "" 5 5 - draft = true 6 6 - 7 7 - -- text.md -- 8 8 - Constraints specify what values are allowed. 9 9 - To CUE they are just values like anything else, 10 10 - but conceptually they can be explained as something in between types and 11 11 - concrete values. 12 12 - 13 13 - Constraints can be used to validate values of concrete instances. 14 14 - They can be applied to CUE data, or directly to YAML or JSON. 15 15 - 16 16 - But constraints can also reduce boilerplate. 17 17 - If a constraints defines a concrete value, there is no need 18 18 - to specify it in values to which this constraint applies.

-69

doc/tutorial/basics/2_types/05_types.txtar

reviewed

··· 1 1 - exec cue eval types.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Type Hierarchy" 6 6 - 7 7 - -- text.md -- 8 8 - CUE defines the following type hierarchy 9 9 - 10 10 - ``` 11 11 - null bool string bytes number struct list 12 12 - / \ 13 13 - int float 14 14 - ``` 15 15 - In addition, CUE defines the values 16 16 - bottom, or error, (denoted `_|_`) 17 17 - that is an instance of all types and 18 18 - top, or any, (denoted `_`) of which all types are an instance. 19 19 - 20 20 - Note how we use the terms types and values interchangeably. 21 21 - CUE does not distinguish between types and values. 22 22 - The term "type" merely refers to the kind of a value, 23 23 - which may or may not be a concrete instance. 24 24 - 25 25 - In the example, `point` defines an arbitrary point, while `xaxis` and `yaxis` 26 26 - define the points on the respective lines. 27 27 - We say that `point`, `xaxis`, and `yaxis` are incomplete, 28 28 - as they do not specify a specific point. 29 29 - Incomplete values cannot be represented as JSON, 30 30 - as it can only represent concrete values. 31 31 - 32 32 - The only concrete point is `origin`. 33 33 - The `origin` is defined to be both on the x-axis and y-axis, which means it 34 34 - must be at `0, 0`. 35 35 - Here we see constraints in action: 36 36 - `origin` evalutes to `0, 0`, even though we did not specify its coordinates 37 37 - explicitly. 38 38 - 39 39 - -- types.cue -- 40 40 - point: { 41 41 - x: number 42 42 - y: number 43 43 - } 44 44 - 45 45 - xaxis: point 46 46 - xaxis: y: 0 47 47 - 48 48 - yaxis: point 49 49 - yaxis: x: 0 50 50 - 51 51 - origin: xaxis & yaxis 52 52 - 53 53 - -- expect-stdout-cue -- 54 54 - point: { 55 55 - x: number 56 56 - y: number 57 57 - } 58 58 - xaxis: { 59 59 - x: number 60 60 - y: 0 61 61 - } 62 62 - yaxis: { 63 63 - x: 0 64 64 - y: number 65 65 - } 66 66 - origin: { 67 67 - x: 0 68 68 - y: 0 69 69 - }

-35

doc/tutorial/basics/2_types/20_bottom.txtar

reviewed

··· 1 1 - exec cue eval -i bottom.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Bottom / Error" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Specifying duplicate fields with conflicting values results in an error 10 10 - or bottom. 11 11 - _Bottom_ is a special value in CUE, denoted `_|_`, that indicates an 12 12 - error such as conflicting values. 13 13 - Any error in CUE results in `_|_`. 14 14 - Logically all errors are equal, although errors may be associated with 15 15 - metadata such as an error message. 16 16 - 17 17 - Note that an error is different from `null`: `null` is a valid value, 18 18 - whereas `_|_` is not. 19 19 - 20 20 - -- bottom.cue -- 21 21 - a: 4 22 22 - a: 5 23 23 - 24 24 - l: [ 1, 2 ] 25 25 - l: [ 1, 3 ] 26 26 - 27 27 - list: [0, 1, 2] 28 28 - val: list[3] 29 29 - 30 30 - -- expect-stdout-cue -- 31 31 - a: _|_ // a: conflicting values 5 and 4 32 32 - l: [1, _|_, // l.1: conflicting values 3 and 2 33 33 - ] 34 34 - list: [0, 1, 2] 35 35 - val: _|_ // val: index out of range [3] with length 3

-45

doc/tutorial/basics/2_types/30_numbers.txtar

reviewed

··· 1 1 - exec cue eval -i numbers.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Numbers" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE defines two kinds of numbers. 10 10 - Integers, denoted `int`, are whole, or integral, numbers. 11 11 - Floats, denoted `float`, are decimal floating point numbers. 12 12 - 13 13 - An integer literal (e.g. `4`) can be of either type, but defaults to `int`. 14 14 - A floating point literal (e.g. `4.0`) is only compatible with `float`. 15 15 - 16 16 - In the example, the result of `b` is a `float` and cannot be 17 17 - used as an `int` without conversion. 18 18 - 19 19 - CUE also adds a variety of sugar for writing numbers. 20 20 - 21 21 - -- numbers.cue -- 22 22 - a: int 23 23 - a: 4 // type int 24 24 - 25 25 - b: number 26 26 - b: 4.0 // type float 27 27 - 28 28 - c: int 29 29 - c: 4.0 30 30 - 31 31 - d: 4 // will evaluate to type int (default) 32 32 - 33 33 - e: [ 34 34 - 1_234, // 1234 35 35 - 5M, // 5_000_000 36 36 - 1.5Gi, // 1_610_612_736 37 37 - 0x1000_0000, // 268_435_456 38 38 - ] 39 39 - 40 40 - -- expect-stdout-cue -- 41 41 - a: 4 42 42 - b: 4.0 43 43 - c: _|_ // c: conflicting values int and 4.0 (mismatched types int and float) 44 44 - d: 4 45 45 - e: [1_234, 5M, 1.5Gi, 0x1000_0000]

-33

doc/tutorial/basics/2_types/40_stringlit.txtar

reviewed

··· 1 1 - exec cue export stringlit.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "String Literals" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE strings allow a richer set of escape sequences than JSON. 10 10 - 11 11 - CUE also supports multi-line strings, enclosed by a pair of triple quotes `"""`. 12 12 - The opening quote must be followed by a newline. 13 13 - The closing quote must also be on a newline. 14 14 - The whitespace directly preceding the closing quote must match the preceding 15 15 - whitespace on all other lines and is removed from these lines. 16 16 - 17 17 - Strings may also contain [interpolations](../../expressions/interpolation). 18 18 - 19 19 - -- stringlit.cue -- 20 20 - // 21-bit unicode characters 21 21 - a: "\U0001F60E" // 😎 22 22 - 23 23 - // multiline strings 24 24 - b: """ 25 25 - Hello 26 26 - World! 27 27 - """ 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - { 31 31 - "a": "😎", 32 32 - "b": "Hello\nWorld!" 33 33 - }

-38

doc/tutorial/basics/2_types/45_stringraw.txtar

reviewed

··· 1 1 - exec cue eval stringraw.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "\"Raw\" Strings" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE does not support raw strings in the strictest sense. 10 10 - Instead it allows modifying the escape delimiter by requiring 11 11 - an arbitrary number of hash `#` signs after the backslash by 12 12 - enclosing a string literal in an equal number of hash signs on either end. 13 13 - 14 14 - This works for normal and interpolated strings. 15 15 - Quotes do not have to be escaped in such strings. 16 16 - 17 17 - -- stringraw.cue -- 18 18 - msg1: #"The sequence "\U0001F604" renders as \#U0001F604."# 19 19 - 20 20 - msg2: ##""" 21 21 - A regular expression can conveniently be written as: 22 22 - 23 23 - #"\d{3}"# 24 24 - 25 25 - This construct works for bytes, strings and their 26 26 - multi-line variants. 27 27 - """## 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - msg1: "The sequence \"\\U0001F604\" renders as 😄." 31 31 - msg2: """ 32 32 - A regular expression can conveniently be written as: 33 33 - 34 34 - #"\\d{3}"# 35 35 - 36 36 - This construct works for bytes, strings and their 37 37 - multi-line variants. 38 38 - """

-24

doc/tutorial/basics/2_types/48_bytes.txtar

reviewed

··· 1 1 - exec cue export bytes.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Bytes" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE distinguishes between a `string` and a `bytes` type. 10 10 - Bytes are converted to base64 when emitting JSON. 11 11 - Byte literals are defined with single quotes. 12 12 - The following additional escape sequences are allowed in byte literals: 13 13 - 14 14 - \xnn // arbitrary byte value defined as a 2-digit hexadecimal number 15 15 - \nnn // arbitrary byte value defined as a 3-digit octal number 16 16 - <!-- jba: this contradicts the spec, which has \nnn (no leading zero) --> 17 17 - 18 18 - -- bytes.cue -- 19 19 - a: '\x03abc' 20 20 - 21 21 - -- expect-stdout-cue -- 22 22 - { 23 23 - "a": "A2FiYw==" 24 24 - }

-36

doc/tutorial/basics/2_types/50_closed.txtar

reviewed

··· 1 1 - exec cue eval -i structs.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Closed structs" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Struct is the most important composite type in CUE. 10 10 - 11 11 - A struct may be open or closed. 12 12 - A closed struct may only be merged with structs that have fields that 13 13 - it defines to be allowed. 14 14 - In other words, closing a struct is equivalent to requiring that all 15 15 - other values be undefined. 16 16 - 17 17 - A closed struct can be created using the `close` builtin, 18 18 - but are more commonly defined using a _definition_, defined next. 19 19 - 20 20 - -- structs.cue -- 21 21 - a: close({ 22 22 - field: int 23 23 - }) 24 24 - 25 25 - b: a & { 26 26 - feild: 3 27 27 - } 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - a: { 31 31 - field: int 32 32 - } 33 33 - b: { 34 34 - field: int 35 35 - feild: _|_ // b.feild: field not allowed 36 36 - }

-37

doc/tutorial/basics/2_types/55_defs.txtar

reviewed

··· 1 1 - exec cue eval -ic defs.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Definitions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - A definition, indicated by an identifier starting with `#` or `_#`, 10 10 - defines values that 11 11 - are not output when converting a configuration to a concrete value. 12 12 - They are used to define schema against which concrete values can 13 13 - be validated. 14 14 - 15 15 - Structs defined by definitions are implicitly closed. 16 16 - 17 17 - -- defs.cue -- 18 18 - msg: "Hello \(#Name)!" 19 19 - 20 20 - #Name: "world" 21 21 - 22 22 - #A: { 23 23 - field: int 24 24 - } 25 25 - 26 26 - a: #A & { field: 3 } 27 27 - err: #A & { feild: 3 } 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - msg: "Hello world!" 31 31 - a: { 32 32 - field: 3 33 33 - } 34 34 - err: { 35 35 - field: int 36 36 - feild: _|_ // err.feild: field not allowed 37 37 - }

-35

doc/tutorial/basics/2_types/56_optional.txtar

reviewed

··· 1 1 - exec cue eval -c structs.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Structs" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Struct is the most important composite type in CUE. 10 10 - Its members are called fields. 11 11 - 12 12 - A struct field may be optional. 13 13 - One can use an optional field to indicate what the type should be if it were 14 14 - specified. 15 15 - A regular (or required) field, on the other hand, must be made concrete 16 16 - for a configuration to be converted to, say, JSON. 17 17 - 18 18 - It is okay for an optional field to be bottom (`_|_`). 19 19 - This just means that field may not be specified. 20 20 - 21 21 - -- structs.cue -- 22 22 - #a: { 23 23 - foo?: int 24 24 - bar?: string 25 25 - baz?: string 26 26 - } 27 27 - b: #a & { 28 28 - foo: 3 29 29 - baz?: 2 // baz?: _|_ 30 30 - } 31 31 - 32 32 - -- expect-stdout-cue -- 33 33 - b: { 34 34 - foo: 3 35 35 - }

-39

doc/tutorial/basics/2_types/60_disjunctions.txtar

reviewed

··· 1 1 - exec cue eval disjunctions.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Disjunctions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Disjunctions, or sum types, define a new type that is one of several things. 10 10 - 11 11 - In the example, our `Conn` definition of earlier is augmented to define 12 12 - the possible values for `protocol`: `"tcp"` or `"udp"`. 13 13 - It is an error for a concrete `Conn` 14 14 - to define anything else than these two values. 15 15 - 16 16 - -- disjunctions.cue -- 17 17 - #Conn: { 18 18 - address: string 19 19 - port: int 20 20 - protocol: "tcp" | "udp" 21 21 - } 22 22 - 23 23 - lossy: #Conn & { 24 24 - address: "1.2.3.4" 25 25 - port: 8888 26 26 - protocol: "udp" 27 27 - } 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - #Conn: { 31 31 - address: string 32 32 - port: int 33 33 - protocol: "tcp" | "udp" 34 34 - } 35 35 - lossy: { 36 36 - address: "1.2.3.4" 37 37 - port: 8888 38 38 - protocol: "udp" 39 39 - }

-29

doc/tutorial/basics/2_types/65_defaults.txtar

reviewed

··· 1 1 - exec cue eval defaults.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Default Values" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Elements of a disjunction may be marked as preferred. 10 10 - If there is only one mark, or the users constraints a field enough such that 11 11 - only one mark remains, that value is the default value. 12 12 - 13 13 - In the example, `replicas` defaults to `1`. 14 14 - In the case of `protocol`, however, there are multiple definitions with 15 15 - different, mutually incompatible defaults. 16 16 - In that case, both `"tcp"` and `"udp"` are preferred and one must explicitly 17 17 - specify either `"tcp"` or `"udp"` as if no marks were given. 18 18 - 19 19 - -- defaults.cue -- 20 20 - // any positive number, 1 is the default 21 21 - replicas: uint | *1 22 22 - 23 23 - // the default value is ambiguous 24 24 - protocol: *"tcp" | "udp" 25 25 - protocol: *"udp" | "tcp" 26 26 - 27 27 - -- expect-stdout-cue -- 28 28 - replicas: 1 29 29 - protocol: "tcp" | "udp"

-25

doc/tutorial/basics/2_types/65_sumstruct.txtar

reviewed

··· 1 1 - -- frontmatter.toml -- 2 2 - title = "Disjunctions of Structs" 3 3 - description = "" 4 4 - 5 5 - -- text.md -- 6 6 - Disjunctions work for any type. 7 7 - 8 8 - In this example we see that a `floor` of some specific house 9 9 - has an exit on level 0 and 1, but not on any other floor. 10 10 - 11 11 - -- sumstruct.cue -- 12 12 - // floor defines the specs of a floor in some house. 13 13 - floor: { 14 14 - level: int // the level on which this floor resides 15 15 - hasExit: bool // is there a door to exit the house? 16 16 - } 17 17 - 18 18 - // constraints on the possible values of floor. 19 19 - floor: { 20 20 - level: 0 | 1 21 21 - hasExit: true 22 22 - } | { 23 23 - level: -1 | 2 | 3 24 24 - hasExit: false 25 25 - }

-37

doc/tutorial/basics/2_types/70_bounds.txtar

reviewed

··· 1 1 - exec cue eval -ic bounds.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Bounds" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Bounds define a lower bound, upper bound, or inequality for a certain value. 10 10 - They work on numbers, strings, bytes and null. 11 11 - 12 12 - The bound is defined for all values for which the corresponding comparison 13 13 - operation is defined. 14 14 - For instance `>5.0` allows all floating point values greater than `5.0`, 15 15 - whereas `<0` allows all negative numbers (int or float). 16 16 - 17 17 - -- bounds.cue -- 18 18 - #rn: >=3 & <8 // type int | float 19 19 - #ri: >=3 & <8 & int // type int 20 20 - #rf: >=3 & <=8.0 // type float 21 21 - #rs: >="a" & <"mo" 22 22 - 23 23 - a: #rn & 3.5 24 24 - b: #ri & 3.5 25 25 - c: #rf & 3 26 26 - d: #rs & "ma" 27 27 - e: #rs & "mu" 28 28 - 29 29 - r1: #rn & >=5 & <10 30 30 - 31 31 - -- expect-stdout-cue -- 32 32 - a: 3.5 33 33 - b: _|_ // b: conflicting values int and 3.5 (mismatched types int and float) 34 34 - c: 3 35 35 - d: "ma" 36 36 - e: _|_ // e: invalid value "mu" (out of bound <"mo") 37 37 - r1: >=5 & <8

-43

doc/tutorial/basics/2_types/75_bounddef.txtar

reviewed

··· 1 1 - exec cue eval -ic bound.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Predefined Bounds" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE numbers have arbitrary precision. 10 10 - Also there is no unsigned integer type. 11 11 - 12 12 - CUE defines the following predefined identifiers to restrict the bounds of 13 13 - integers to common values. 14 14 - 15 15 - ``` 16 16 - uint >=0 17 17 - uint8 >=0 & <=255 18 18 - int8 >=-128 & <=127 19 19 - uint16 >=0 & <=65536 20 20 - int16 >=-32_768 & <=32_767 21 21 - rune >=0 & <=0x10FFFF 22 22 - uint32 >=0 & <=4_294_967_296 23 23 - int32 >=-2_147_483_648 & <=2_147_483_647 24 24 - uint64 >=0 & <=18_446_744_073_709_551_615 25 25 - int64 >=-9_223_372_036_854_775_808 & <=9_223_372_036_854_775_807 26 26 - int128 >=-170_141_183_460_469_231_731_687_303_715_884_105_728 & 27 27 - <=170_141_183_460_469_231_731_687_303_715_884_105_727 28 28 - uint128 >=0 & <=340_282_366_920_938_463_463_374_607_431_768_211_455 29 29 - ``` 30 30 - 31 31 - -- bound.cue -- 32 32 - #positive: uint 33 33 - #byte: uint8 34 34 - #word: int32 35 35 - 36 36 - a: #positive & -1 37 37 - b: #byte & 128 38 38 - c: #word & 2_000_000_000 39 39 - 40 40 - -- expect-stdout-cue -- 41 41 - a: _|_ // a: invalid value -1 (out of bound >=0) 42 42 - b: 128 43 43 - c: 2000000000

-45

doc/tutorial/basics/2_types/80_lists.txtar

reviewed

··· 1 1 - exec cue eval -i lists.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Lists" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Lists define arbitrary sequences of CUE values. 10 10 - A list can be closed or open ended. 11 11 - Open-ended lists may have some predefined elements, but may have 12 12 - additional, possibly typed elements. 13 13 - 14 14 - In the example we define `IP` to be a list of `4` elements of type `uint8`, which 15 15 - is a predeclared value of `>=0 & <=255`. 16 16 - `PrivateIP` defines the IP ranges defined for private use. 17 17 - Note that as it is already defined to be an `IP`, the length of the list 18 18 - is already fixed at `4` and we do not have to specify a value for all elements. 19 19 - Also note that instead of writing `...uint8`, we could have written `...` 20 20 - as the type constraint is already implied by `IP`. 21 21 - 22 22 - The output contains a valid private IP address (`myIP`) 23 23 - and an invalid one (`yourIP`). 24 24 - 25 25 - -- lists.cue -- 26 26 - import "list" 27 27 - 28 28 - IP: list.Repeat([ uint8 ], 4) 29 29 - 30 30 - PrivateIP: IP 31 31 - PrivateIP: [10, ...uint8] | 32 32 - [192, 168, ...] | 33 33 - [172, >=16 & <=32, ...] 34 34 - 35 35 - myIP: PrivateIP 36 36 - myIP: [10, 2, 3, 4] 37 37 - 38 38 - yourIP: PrivateIP 39 39 - yourIP: [11, 1, 2, 3] 40 40 - 41 41 - -- expect-stdout-cue -- 42 42 - IP: [uint8, uint8, uint8, uint8] 43 43 - PrivateIP: [10, uint8, uint8, uint8] | [192, 168, uint8, uint8] | [172, uint & >=16 & <=32, uint8, uint8] 44 44 - myIP: [10, 2, 3, 4] 45 45 - yourIP: _|_ // yourIP: 3 errors in empty disjunction: (and 3 more errors)

-50

doc/tutorial/basics/2_types/90_templates.txtar

reviewed

··· 1 1 - exec cue eval templates.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Templates" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - One of CUE's most powerful features is the ability 10 10 - to specify optional fields in bulk. 11 11 - This allows one to specify constraints, 12 12 - or templates, 13 13 - to be unified with each field of a struct. 14 14 - 15 15 - An optional field set is an expression in square brackets 16 16 - to specify to which fields to apply a constraint 17 17 - (currently only `string`, or all fields is supported). 18 18 - Using an alias in the square brackets binds the 19 19 - label of the matched field to the given identifier, 20 20 - which can then be used within the template. 21 21 - 22 22 - -- templates.cue -- 23 23 - // The following struct is unified with all elements in job. 24 24 - // The name of each element is bound to Name and visible in the struct. 25 25 - job: [Name=_]: { 26 26 - name: Name 27 27 - replicas: uint | *1 28 28 - command: string 29 29 - } 30 30 - 31 31 - job: list: command: "ls" 32 32 - 33 33 - job: nginx: { 34 34 - command: "nginx" 35 35 - replicas: 2 36 36 - } 37 37 - 38 38 - -- expect-stdout-cue -- 39 39 - job: { 40 40 - list: { 41 41 - name: "list" 42 42 - replicas: 1 43 43 - command: "ls" 44 44 - } 45 45 - nginx: { 46 46 - name: "nginx" 47 47 - command: "nginx" 48 48 - replicas: 2 49 49 - } 50 50 - }

-35

doc/tutorial/basics/4_references/10_scopes.txtar

reviewed

··· 1 1 - exec cue eval scopes.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "References and Scopes" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - A reference refers to the value of the field defined within the nearest 10 10 - enclosing scope. 11 11 - 12 12 - If no field matches the reference within the file, it may match a top-level 13 13 - field defined in any other file of the same package. 14 14 - 15 15 - If there is still no match, it may match a predefined value. 16 16 - 17 17 - -- scopes.cue -- 18 18 - v: 1 19 19 - a: { 20 20 - v: 2 21 21 - b: v // matches the inner v 22 22 - } 23 23 - a: { 24 24 - c: v // matches the top-level v 25 25 - } 26 26 - b: v 27 27 - 28 28 - -- expect-stdout-cue -- 29 29 - v: 1 30 30 - a: { 31 31 - v: 2 32 32 - c: 1 33 33 - b: 2 34 34 - } 35 35 - b: 1

-27

doc/tutorial/basics/4_references/20_selectors.txtar

reviewed

··· 1 1 - exec cue eval selectors.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Accessing Fields" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Selectors access fields within a struct using the `.` notation. 10 10 - This only works if a field name is a valid identifier and it is not computed. 11 11 - For other cases one can use the indexing notation. 12 12 - 13 13 - -- selectors.cue -- 14 14 - a: { 15 15 - b: 2 16 16 - "c-e": 5 17 17 - } 18 18 - v: a.b 19 19 - w: a["c-e"] 20 20 - 21 21 - -- expect-stdout-cue -- 22 22 - a: { 23 23 - b: 2 24 24 - "c-e": 5 25 25 - } 26 26 - v: 2 27 27 - w: 5

-37

doc/tutorial/basics/4_references/30_aliases.txtar

reviewed

··· 1 1 - exec cue eval alias.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Aliases" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - An alias defines a local macro. 10 10 - 11 11 - A typical use case is to provide access to a shadowed field. 12 12 - 13 13 - Aliases are not members of a struct. They can be referred to only within the 14 14 - struct, and they do not appear in the output. 15 15 - 16 16 - -- alias.cue -- 17 17 - let A = a // A is an alias for a 18 18 - a: { 19 19 - d: 3 20 20 - } 21 21 - b: { 22 22 - a: { 23 23 - // A provides access to the outer "a" which would 24 24 - // otherwise be hidden by the inner one. 25 25 - c: A.d 26 26 - } 27 27 - } 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - a: { 31 31 - d: 3 32 32 - } 33 33 - b: { 34 34 - a: { 35 35 - c: 3 36 36 - } 37 37 - }

-22

doc/tutorial/basics/4_references/50_emit.txtar

reviewed

··· 1 1 - exec cue export emit.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Emit Values" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - By default all top-level fields are emitted when evaluating a configuration. 10 10 - Embedding a value at top-level will cause that value to be emitted instead. 11 11 - 12 12 - Emit values allow CUE configurations, like JSON, 13 13 - to define any type, instead of just structs, while keeping the common case 14 14 - of defining structs light. 15 15 - 16 16 - -- emit.cue -- 17 17 - "Hello \(#who)!" 18 18 - 19 19 - #who: "world" 20 20 - 21 21 - -- expect-stdout-cue -- 22 22 - "Hello world!"

-34

doc/tutorial/basics/4_references/80_cycle.txtar

reviewed

··· 1 1 - # Note: the output here is wrong. Reported as cuelang.org/issue/2342 2 2 - exec cue eval -i -c cycle.cue 3 3 - cmp stdout expect-stdout-cue 4 4 - 5 5 - -- frontmatter.toml -- 6 6 - title = "Reference Cycles" 7 7 - description = "" 8 8 - 9 9 - -- text.md -- 10 10 - CUE can handle many types of cycles just fine. 11 11 - Because all values are final, a field with a concrete value of, say `200`, 12 12 - can only be valid if it is that value. 13 13 - So if it is unified with another expression, we can delay the evaluation of 14 14 - this until later. 15 15 - 16 16 - By postponing that evaluation, we can often break cycles. 17 17 - This is very useful for template writers that may not know what fields 18 18 - a user will want to fill out. 19 19 - 20 20 - -- cycle.cue -- 21 21 - // CUE knows how to resolve the following: 22 22 - x: 200 23 23 - x: y + 100 24 24 - y: x - 100 25 25 - 26 26 - // If a cycle is not broken, CUE will just report it. 27 27 - a: b + 100 28 28 - b: a - 100 29 29 - 30 30 - -- expect-stdout-cue -- 31 31 - x: 200 32 32 - y: 100 33 33 - a: b + 100 34 34 - b: a - 100

-29

doc/tutorial/basics/4_references/85_cycleref.txtar

reviewed

··· 1 1 - exec cue eval cycleref.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Cycles in Fields" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Also, we know that unifying a field with itself will result in the same value. 10 10 - Thus if we have a cycle between some fields, all we need to do is ignore 11 11 - the cycle and unify their values once to achieve the same result as 12 12 - merging them ad infinitum. 13 13 - 14 14 - -- cycleref.cue -- 15 15 - labels: selectors 16 16 - labels: {app: "foo"} 17 17 - 18 18 - selectors: labels 19 19 - selectors: {name: "bar"} 20 20 - 21 21 - -- expect-stdout-cue -- 22 22 - labels: { 23 23 - app: "foo" 24 24 - name: "bar" 25 25 - } 26 26 - selectors: { 27 27 - name: "bar" 28 28 - app: "foo" 29 29 - }

-27

doc/tutorial/basics/4_references/99_hidden.txtar

reviewed

··· 1 1 - exec cue export hidden.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Hidden Fields" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - A non-quoted field name that starts with an underscore (`_`) is not 10 10 - emitted from the output. 11 11 - To include fields in the configuration that start with an underscore 12 12 - put them in quotes. 13 13 - 14 14 - Quoted and non-quoted fields share the same namespace unless they start 15 15 - with an underscore. 16 16 - 17 17 - -- hidden.cue -- 18 18 - "_foo": 2 19 19 - _foo: 3 20 20 - foo: 4 21 21 - _#foo: 5 22 22 - 23 23 - -- expect-stdout-cue -- 24 24 - { 25 25 - "_foo": 2, 26 26 - "foo": 4 27 27 - }

-30

doc/tutorial/basics/6_expressions/10_operators.txtar

reviewed

··· 1 1 - exec cue eval -i op.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Operators" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE supports many common arithmetic and boolean operators. 10 10 - 11 11 - The operators for division and remainder are different for `int` and `float`. 12 12 - For `float` CUE supports the `/` operator with the usual meaning. 13 13 - For `int` CUE supports both Euclidean division (`div` and `mod`) 14 14 - and truncated division (`quo` and `rem`). 15 15 - 16 16 - -- op.cue -- 17 17 - a: 3 / 2 // type float 18 18 - b: 3 div 2 // type int: Euclidean division 19 19 - 20 20 - c: 3 * "blah" 21 21 - d: 3 * [1, 2, 3] 22 22 - 23 23 - e: 8 < 10 24 24 - 25 25 - -- expect-stdout-cue -- 26 26 - a: 1.5 27 27 - b: 1 28 28 - c: "blahblahblah" 29 29 - d: [1, 2, 3, 1, 2, 3, 1, 2, 3] 30 30 - e: true

-23

doc/tutorial/basics/6_expressions/20_interpolation.txtar

reviewed

··· 1 1 - exec cue eval interpolation.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Interpolation" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - String and bytes literals support interpolation. 10 10 - 11 11 - Any valid CUE expression may be used inside the escaped parentheses. 12 12 - Interpolation may also be used in multiline string and byte literals. 13 13 - 14 14 - -- interpolation.cue -- 15 15 - "You are \( #cost - #budget ) dollars over budget!" 16 16 - 17 17 - #cost: 102 18 18 - #budget: 88 19 19 - 20 20 - -- expect-stdout-cue -- 21 21 - "You are 14 dollars over budget!" 22 22 - #cost: 102 23 23 - #budget: 88

-23

doc/tutorial/basics/6_expressions/25_interpolfield.txtar

reviewed

··· 1 1 - ! exec cue eval genfield.cue 2 2 - cmp stderr expect-stderr 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Interpolation of Field Names" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - String interpolations may also be used in field names. 10 10 - 11 11 - One cannot refer to generated fields with references. 12 12 - 13 13 - -- genfield.cue -- 14 14 - sandwich: { 15 15 - type: "Cheese" 16 16 - "has\(type)": true 17 17 - hasButter: true 18 18 - butterAndCheese: hasButter && hasCheese 19 19 - } 20 20 - 21 21 - -- expect-stderr -- 22 22 - sandwich.butterAndCheese: reference "hasCheese" not found: 23 23 - ./genfield.cue:5:35

-24

doc/tutorial/basics/6_expressions/40_listcomp.txtar

reviewed

··· 1 1 - exec cue export listcomp.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "List Comprehensions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Lists can be created with list comprehensions. 10 10 - 11 11 - The example shows the use of `for` loops and `if` guards. 12 12 - 13 13 - -- listcomp.cue -- 14 14 - [for x in #items if x rem 2 == 0 { x*x }] 15 15 - 16 16 - #items: [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ] 17 17 - 18 18 - -- expect-stdout-cue -- 19 19 - [ 20 20 - 4, 21 21 - 16, 22 22 - 36, 23 23 - 64 24 24 - ]

-42

doc/tutorial/basics/6_expressions/50_fieldcomp.txtar

reviewed

··· 1 1 - exec cue eval -c fieldcomp.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Field Comprehensions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - CUE also supports comprehensions for fields. 10 10 - 11 11 - One cannot refer to generated fields with references. 12 12 - Instead, one must use indexing. 13 13 - 14 14 - -- fieldcomp.cue -- 15 15 - import "strings" 16 16 - 17 17 - #a: ["Barcelona", "Shanghai", "Munich"] 18 18 - 19 19 - for k, v in #a { 20 20 - "\( strings.ToLower(v) )": { 21 21 - pos: k + 1 22 22 - name: v 23 23 - nameLen: len(v) 24 24 - } 25 25 - } 26 26 - 27 27 - -- expect-stdout-cue -- 28 28 - barcelona: { 29 29 - pos: 1 30 30 - name: "Barcelona" 31 31 - nameLen: 9 32 32 - } 33 33 - shanghai: { 34 34 - pos: 2 35 35 - name: "Shanghai" 36 36 - nameLen: 8 37 37 - } 38 38 - munich: { 39 39 - pos: 3 40 40 - name: "Munich" 41 41 - nameLen: 6 42 42 - }

-27

doc/tutorial/basics/6_expressions/55_conditional.txtar

reviewed

··· 1 1 - exec cue eval conditional.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Conditional Fields" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - Field comprehensions can also be used to 10 10 - add a single field conditionally. 11 11 - 12 12 - Converting the resulting configuration to JSON results in an error 13 13 - as `justification` is required yet no concrete value is given. 14 14 - 15 15 - -- conditional.cue -- 16 16 - price: number 17 17 - 18 18 - // Require a justification if price is too high 19 19 - if price > 100 { 20 20 - justification: string 21 21 - } 22 22 - 23 23 - price: 200 24 24 - 25 25 - -- expect-stdout-cue -- 26 26 - justification: string 27 27 - price: 200

-34

doc/tutorial/basics/6_expressions/70_regexp.txtar

reviewed

··· 1 1 - exec cue eval -i regexp.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Regular expressions" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - The `=~` and `!~` operators can be used to check against regular expressions. 10 10 - 11 11 - The expression `a =~ b` is true if `a` matches `b`, while 12 12 - `a !~ b` is true if `a` does _not_ match `b`. 13 13 - 14 14 - Just as with comparison operators, these operators may be used 15 15 - as unary versions to define a set of strings. 16 16 - 17 17 - -- regexp.cue -- 18 18 - a: "foo bar" =~ "foo [a-z]{3}" 19 19 - b: "maze" !~ "^[a-z]{3}$" 20 20 - 21 21 - c: =~"^[a-z]{3}$" // any string with lowercase ASCII of length 3 22 22 - 23 23 - d: c 24 24 - d: "foo" 25 25 - 26 26 - e: c 27 27 - e: "foo bar" 28 28 - 29 29 - -- expect-stdout-cue -- 30 30 - a: true 31 31 - b: true 32 32 - c: =~"^[a-z]{3}$" 33 33 - d: "foo" 34 34 - e: _|_ // e: invalid value "foo bar" (out of bound =~"^[a-z]{3}$")

-44

doc/tutorial/basics/6_expressions/80_coalesce.txtar

reviewed

··· 1 1 - exec cue eval coalesce.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Null Coalescing" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - <!-- jba: the terms here are confusing. "Null coalescing" is actually not 10 10 - that, but then there is something called "actual null coalescing." 11 11 - 12 12 - Just say that because _|_ | X evaluates to X, you can use disjunction 13 13 - to represent fallback values. 14 14 - 15 15 - And then you can use that to effectively type-check with a default value. 16 16 - --> 17 17 - 18 18 - With null coalescing we really mean error, or bottom, coalescing. 19 19 - The defaults mechanism for disjunctions can also be 20 20 - used to provide fallback values in case an expression evaluates to bottom. 21 21 - 22 22 - In the example the fallback values are specified 23 23 - for `a` and `b` in case the list index is out of bounds. 24 24 - 25 25 - To do actual null coalescing one can unify a result with the desired type 26 26 - to force an error. 27 27 - In that case the default will be used if either the lookup fails or 28 28 - the result is not of the desired type. 29 29 - 30 30 - -- coalesce.cue -- 31 31 - list: ["Cat", "Mouse", "Dog"] 32 32 - 33 33 - a: *list[0] | "None" 34 34 - b: *list[5] | "None" 35 35 - 36 36 - n: [null] 37 37 - v: *(n[0]&string) | "default" 38 38 - 39 39 - -- expect-stdout-cue -- 40 40 - list: ["Cat", "Mouse", "Dog"] 41 41 - a: "Cat" 42 42 - b: "None" 43 43 - n: [null] 44 44 - v: "default"

-34

doc/tutorial/basics/8_packages/10_packages.txtar

reviewed

··· 1 1 - exec cue eval a.cue b.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Packages" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - A CUE file is a standalone file by default. 10 10 - A `package` clause allows a single configuration to be split across multiple 11 11 - files. 12 12 - 13 13 - The configuration for a package is defined by the concatenation of all its 14 14 - files, after stripping the package clauses and not considering imports. 15 15 - 16 16 - Duplicate definitions are treated analogously to duplicate definitions within 17 17 - the same file. 18 18 - The order in which files are loaded is undefined, but any order will result 19 19 - in the same outcome, given that order does not matter. 20 20 - 21 21 - -- a.cue -- 22 22 - package config 23 23 - 24 24 - foo: 100 25 25 - bar: int 26 26 - 27 27 - -- b.cue -- 28 28 - package config 29 29 - 30 30 - bar: 200 31 31 - 32 32 - -- expect-stdout-cue -- 33 33 - foo: 100 34 34 - bar: 200

-34

doc/tutorial/basics/8_packages/30_imports.txtar

reviewed

··· 1 1 - exec cue eval imports.cue 2 2 - cmp stdout expect-stdout-cue 3 3 - 4 4 - -- frontmatter.toml -- 5 5 - title = "Imports" 6 6 - description = "" 7 7 - 8 8 - -- text.md -- 9 9 - A CUE file may import definitions from builtin or user-defined packages. 10 10 - A CUE file does not need to be part of a package to use imports. 11 11 - 12 12 - The example here shows the use of builtin packages. 13 13 - 14 14 - This code groups the imports into a parenthesized, "factored" import statement. 15 15 - 16 16 - You can also write multiple import statements, like: 17 17 - 18 18 - ``` 19 19 - import "encoding/json" 20 20 - import "math" 21 21 - ``` 22 22 - 23 23 - But it is good style to use the factored import statement. 24 24 - 25 25 - -- imports.cue -- 26 26 - import ( 27 27 - "encoding/json" 28 28 - "math" 29 29 - ) 30 30 - 31 31 - data: json.Marshal({ a: math.Sqrt(7) }) 32 32 - 33 33 - -- expect-stdout-cue -- 34 34 - data: "{\"a\":2.6457513110645907}"

+4

doc/tutorial/basics/README.md

reviewed

··· 1 1 + # CUE Tour 2 2 + 3 3 + The CUE Tour has now moved to https://cuelang.org/docs/tour/ with the source 4 4 + available under https://github.com/cue-lang/cuelang.org/tree/master/content/docs/tour.

-16

doc/tutorial/basics/Readme.md

reviewed

··· 1 1 - # CUE Tour 2 2 - 3 3 - ## About this tutorial 4 4 - 5 5 - The files in this directory are used to generate the tour in 6 6 - 7 7 - https://cuelang.org/docs/tutorials/tour/intro/ 8 8 - 9 9 - They are kept here to ensure the examples are in sync with the latest update 10 10 - of CUE. 11 11 - 12 12 - To try out the examples in the tutorial you can follow the 13 13 - [installation instructions](../../../README.md#download-and-install) 14 14 - to get a working setup of CUE. 15 15 - 16 16 - Use the `cue eval` or `cue export` commands to evaluate an example.

-81

doc/tutorial/basics/script_test.go

reviewed

··· 1 1 - package basics 2 2 - 3 3 - import ( 4 4 - "io/fs" 5 5 - "os" 6 6 - "path" 7 7 - "path/filepath" 8 8 - "regexp" 9 9 - "strings" 10 10 - "testing" 11 11 - 12 12 - "github.com/rogpeppe/go-internal/testscript" 13 13 - "golang.org/x/tools/txtar" 14 14 - 15 15 - "cuelang.org/go/cmd/cue/cmd" 16 16 - "cuelang.org/go/cue/parser" 17 17 - "cuelang.org/go/internal/cuetest" 18 18 - ) 19 19 - 20 20 - // TestLatest checks that the examples match the latest language standard, 21 21 - // even if still valid in backwards compatibility mode. 22 22 - func TestLatest(t *testing.T) { 23 23 - if err := filepath.WalkDir(".", func(fullpath string, entry fs.DirEntry, err error) error { 24 24 - if err != nil { 25 25 - return err 26 26 - } 27 27 - if !strings.HasSuffix(fullpath, ".txtar") { 28 28 - return nil 29 29 - } 30 30 - 31 31 - a, err := txtar.ParseFile(fullpath) 32 32 - if err != nil { 33 33 - return err 34 34 - } 35 35 - 36 36 - for _, f := range a.Files { 37 37 - t.Run(path.Join(fullpath, f.Name), func(t *testing.T) { 38 38 - if !strings.HasSuffix(f.Name, ".cue") { 39 39 - return 40 40 - } 41 41 - v := parser.FromVersion(parser.Latest) 42 42 - _, err := parser.ParseFile(f.Name, f.Data, v) 43 43 - if err != nil { 44 44 - t.Errorf("%v: %v", fullpath, err) 45 45 - } 46 46 - }) 47 47 - } 48 48 - return nil 49 49 - }); err != nil { 50 50 - t.Fatal(err) 51 51 - } 52 52 - } 53 53 - 54 54 - func TestScript(t *testing.T) { 55 55 - tourDir := regexp.MustCompile(`^\d+_.+`) 56 56 - entries, err := os.ReadDir(".") 57 57 - if err != nil { 58 58 - t.Fatal(err) 59 59 - } 60 60 - didWork := false 61 61 - for _, entry := range entries { 62 62 - if !entry.IsDir() || !tourDir.MatchString(entry.Name()) { 63 63 - continue 64 64 - } 65 65 - didWork = true 66 66 - testscript.Run(t, testscript.Params{ 67 67 - Dir: entry.Name(), 68 68 - UpdateScripts: cuetest.UpdateGoldenFiles, 69 69 - RequireExplicitExec: true, 70 70 - }) 71 71 - } 72 72 - if !didWork { 73 73 - t.Fatal("failed to find any steps in the tour") 74 74 - } 75 75 - } 76 76 - 77 77 - func TestMain(m *testing.M) { 78 78 - os.Exit(testscript.RunMain(m, map[string]func() int{ 79 79 - "cue": cmd.Main, 80 80 - })) 81 81 - }