User-defined functions?

[zombiezen]

Is there a convenient way of creating user-defined functions or something similar? Under boilerplate removal, the pattern constraint is used to imply a default constraint, but sometimes I want to build a value based on some set of input parameters (not just a single string). The best I can come up with now is:

#udf: {
  #foo: string
  out: "\(#foo)bar"
}

"quux": (#udf & {#foo: "foo"}).out

[zombiezen]

From @myitcv in Slack: this is the correct way to go for now, but the new evaluator will make this better by allowing non-structs to be emitted. Combined with type cast semantics (like those I proposed in #454), this will make these sorts of limited functions much easier to work with.

[mpvl]

We are also contemplating a syntactic sugar for the arguments, allowing the above to be written as

#udf: {
  #0: string
  
  "\(#0)bar"
}

"quux": #udf("foo")

#0 would just be a regular field otherwise. This approach avoids some of the pitfalls of having functions in a configuration language.

Note that the new evaluator now explicitly disallows reentrancy. This was already disallowed by the spec, but not previously enforced.

[mpvl]

For completeness, we are also investigating a native bridge to some regular language, perhaps only to be done in the tooling layer.

The idea is that a configuration language is not the best place to do computation and that this is best left to an established general programming language. Rather than enhancing CUE with the ability of computation, we use CUE's commutativity to mix in computed results. The strict separation of computation and configuration, combined with CUE's commutativity property, allows computation to be ignored leaving a non-concrete pure CUE configuration that can be refactored and analyzed with tools like trim and anti-unification. Many of the possible analysis tools would break down if we start to blur the lines between computation and configuration.

Either way, the idea is still to allow simple "macros" to allow dealing with simple cases within CUE itself.

[myitcv]

For those who view this answer, there was further discussion about the syntactic sugar for functions in #69 (comment)

[PierreR]

Talking about native bridge is webAssembly in the picture to propose an interface for various programming languages ?

[myitcv]

The current best answer is:

foo: {#a: int, #b: int, #a + #b } // struct with embedded scalar
call: foo&{_, #a: 1, #b: 2}         // 3

(a change from the previously marked answer because we now have full support for embedded scalars)

There is a proposal to support a syntactic sugar based on this:

foo: { #a: int, #b: int, #a + #b } // struct with embedded scalar
call: foo(#a: 1, #b: 2) // 3

[codewithcheese]

@myitcv with cue eval --concrete the above returns foo: non-concrete value int in operand to +: ./demo/func.cue:25:25

[myitcv]

@codewithcheese please can you raise an issue if you're seeing an issue with this? Thanks

[morlay]

@myitcv your case will be throw the errors. (v0.3.0-beta.7)

@codewithcheese function should be a hidden one _ or # prefix

_foo: {#a: int, #b: int, #a + #b }
call: _foo & {_, #a: 1, #b: 2} 

[myitcv]

@morlay

@myitcv your case will be throw the errors. (v0.3.0-beta.7)

Apologies, I'm not sure what you're referring to here. Are you suggesting there's an issue with beta.7? If so, please can you give an example of what is failing?

[vikstrous2]

Taking this idea a step further and adding a conditional:

cond: true
foo: {
  #a: int
  #b: int
  if cond  { output: #a + #b }
  if !cond { output: 4 }
} // struct with embedded scalar
call: (foo&{#a: 1, #b: 2}).output         // 3

The conditional version doesn't work with the embedding scalars approach.

[myitcv]

It should work with embedded scalars. So I just raised #729. Thanks for pointing this out.

[cueckoo]

This discussion has been migrated to cue-lang/cue#484.

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