summaryrefslogtreecommitdiffhomepage
path: root/cue.html.markdown
diff options
context:
space:
mode:
authorven <vendethiel@hotmail.fr>2024-01-15 23:48:29 +0100
committerGitHub <noreply@github.com>2024-01-15 23:48:29 +0100
commit8a264b945ac3d664ef8dc61e755ed9b6c3797513 (patch)
treed9acf85129e3cb72bb851788a5ef5af29c2e7468 /cue.html.markdown
parent2dba5b129445a7455db9986b482327ebdbcc2c1c (diff)
Update cue.html.markdown
Try to fix https://github.com/adambard/learnxinyminutes-site/issues/113
Diffstat (limited to 'cue.html.markdown')
-rw-r--r--cue.html.markdown52
1 files changed, 26 insertions, 26 deletions
diff --git a/cue.html.markdown b/cue.html.markdown
index 5960c453..a1b76ada 100644
--- a/cue.html.markdown
+++ b/cue.html.markdown
@@ -12,12 +12,12 @@ CUE is an expressive (but not Turing-complete) JSON superset, exportable to JSON
When CUE is exported to JSON, values from every processed file are unified into one giant object. Consider these two files:
-```cue
+```yaml
//name.cue
name: "Daniel"
```
-```cue
+```yaml
//disposition.cue
disposition: "oblivious"
```
@@ -40,19 +40,19 @@ disposition: oblivious
Notice the C-style comments are not in the output. Also notice that the keys in CUE syntax did not require quotes. Some special characters do require quotes:
-```cue
+```yaml
works_fine: true
"needs-quotes": true
```
Unification doesn't just unify across files, it is also a *global merge* of all types and values. The following fails, because the *types* are different.
-```cue
+```yaml
//string_value.cue
foo: "baz"
```
-```cue
+```yaml
//integer_value.cue
foo: 100
```
@@ -66,12 +66,12 @@ foo: conflicting values "baz" and 100 (mismatched types string and int):
But even if we quote the integer, it still fails, because the *values* conflict and there is no way to unify everything into a top-level object.
-```cue
+```yaml
//string_value.cue
foo: "baz"
```
-```cue
+```yaml
//integer_value.cue
foo: "100" // a string now
```
@@ -85,14 +85,14 @@ foo: conflicting values "100" and "baz":
Types in CUE *are* values; special ones that the unification engine knows have certain behavior relative to other values. During unification it requires that values match the specified types, and when concrete values are required, you will get an error if there's only a type. So this is fine:
-```cue
+```yaml
street: "1 Infinite Loop"
street: string
```
While `cue export` produces YAML or JSON, `cue eval` produces CUE. This is useful for converting YAML or JSON to CUE, or for inspecting the unified output in CUE itself. It's fine to be missing concrete values in CUE (though it prefers concrete values when emitting CUE when both are available and match),
-```cue
+```yaml
//type-only.cue
amount: float
```
@@ -111,7 +111,7 @@ amount: incomplete value float
Give it a value that unifies with the type, and all is well.
-```cue
+```yaml
//concrete-value.cue
amount: 3.14
```
@@ -127,7 +127,7 @@ The method of unifying concrete values with types that share a common syntax is
Default values may be supplied with a type using an asterisk:
-```cue
+```yaml
// default-port.cue
port: int | *8080
```
@@ -139,7 +139,7 @@ port: 8080
Enum-style options ("disjunctions" in CUE) may be specified with an `|` separator:
-```cue
+```yaml
//severity-enum.cue
severity: "high" | "medium" | "low"
severity: "unknown"
@@ -163,7 +163,7 @@ You can even have disjunctions of structs (not shown, but it works like you'd ex
CUE has "definitions", and you can use them like you would variable declarations in other languages. They are also for defining struct types. You can apply a struct of type definitions to some concrete value(s) with `&`. Also notice you can say "a list with type #Whatever" using `[...#Whatever]`.
-```cue
+```yaml
// definitions.cue
#DashboardPort: 1337
@@ -208,7 +208,7 @@ more_addresses:
CUE supports more complex values and validation:
-```cue
+```yaml
#Country: {
name: =~"^\\p{Lu}" // Must start with an upper-case letter
pop: >800 & <9_000_000_000 // More than 800, fewer than 9 billion
@@ -222,7 +222,7 @@ vatican_city: #Country & {
CUE may save you quite a bit of time with all the sugar it provides on top of mere JSON. Here we're defining, "modifying", and validating a nested structure in three lines: (Notice the `[]` syntax used around `string` to signal to the engine that `string` is a constraint, not a string in this case.)
-```cue
+```yaml
//paths.cue
// path-value pairs
@@ -249,7 +249,7 @@ outer: [string]: inner: int
In the same vein, CUE supports "templates", which are a bit like functions of a single argument. Here `Name` is bound to each string key immediately under `container` while the struct underneath *that* is evaluated.
-```cue
+```yaml
//templates.cue
container: [Name=_]: {
@@ -284,7 +284,7 @@ container: {
And while we're talking about references like that, CUE supports scoped references.
-```cue
+```yaml
//scopes-and-references.cue
v: "top-level v"
b: v // a reference
@@ -320,7 +320,7 @@ I changed the order of the keys in the output for clarity. Order doesn't actuall
You can hide fields be prefixing them with `_` (quote the field if you need a `_` prefix in an emitted field)
-```cue
+```yaml
//hiddens.cue
"_foo": 2
_foo: 3
@@ -346,7 +346,7 @@ Notice the difference between `eval` and `export` with respect to definitions. I
Interpolation of values and fields:
-```cue
+```yaml
//interpolation.cue
#expense: 90
@@ -372,7 +372,7 @@ cat: {
Operators, list comprehensions, conditionals, imports...:
-```cue
+```yaml
//getting-out-of-hand-now.cue
import "strings" // we'll come back to this
@@ -446,7 +446,7 @@ At this point it's worth mentioning that CUE may not be Turing-complete, but it
To that end, CUE supports packages and modules. CUE files are standalone by default, but if you put a package clause at the top, you're saying that file is unifiable with other files "in" the same package.
-```cue
+```yaml
//a.cue
package config
@@ -454,7 +454,7 @@ foo: 100
bar: int
```
-```cue
+```yaml
//b.cue
package config
@@ -508,7 +508,7 @@ configuredBar: 200
The contents of `main.cue` is:
-```cue
+```yaml
//main.cue
package main
@@ -519,7 +519,7 @@ configuredBar: config.bar
`config/a.cue` and `config/b.cue` are files from earlier, except now they've both got `package config` at the top:
-```cue
+```yaml
//a.cue
package config
@@ -527,7 +527,7 @@ foo: 100
bar: int
```
-```cue
+```yaml
//b.cue
package config
@@ -548,4 +548,4 @@ That's it for now. I understand there are more package management features comin
Finally, CUE has built-in modules with powerful functionality. We saw one of these earlier, when we imported "strings" and used `strings.ToLower`. Imports without fully-qualified module names are assumed to be built-ins. The full list and documentation for each is here: https://pkg.go.dev/cuelang.org/go/pkg
-This has been a condensation of the official docs and tutorials, so go give the source material some love: https://cuelang.org/docs/tutorials/ \ No newline at end of file
+This has been a condensation of the official docs and tutorials, so go give the source material some love: https://cuelang.org/docs/tutorials/