Nix-style "inherit"

[cueckoo]

Originally opened by @nyarly in cuelang/cue#847

I'm finding (and perhaps I'm discovering an anti-pattern) that I've got a lot of structs, often in a "function" style

foo: {
  parm: string
  result: #Def & { "parm": parm }
}

//used as
(foo & {parm: "bar}).result

One thing of note is the pattern of using a explicit string as a struct field name, to prevent CUE seeing it as a identifier and recursively trying to resolve it.

But when there's even a few parameters, it feels stuttery (a la Go style.)

Three other languages that occur to me have recognized this stylistic issue, and addressed it. ECMAScript simply allows bare names in { } to be the equivalent of using the enclosing variable value and the object value. Rust does likewise.

Nix, on the other hand, has an inherit keyword, that takes a list of identifiers. The advantage of this feature is that inherit can also take a parenthesized identifier as a source of inheriting values, which means that a set (~= a struct) can be built up from other sets very easily.

For the above example, an ES/Rust style would look like

foo: {
 parm: string
 result: #Def & { parm }
 }

Nix style:

foo: {
  parm: string
  result: #Def & { inherit parm }
}

[cueckoo]

Original reply by @verdverm in cuelang/cue#847 (comment)

Related to #484 and cuelang/cue#69 (comment)

• The bare name already has a semantic meaning, to embed the value into the struct
• The proposed "function" syntax may help, but depends on how you define it. Look into the #0, #1 idea @mpvl brought up
• The Query Proposal is also relevant Proposal: CUE Querying extension cuelang/cue#165

inherit (or an embedding) cloud be achieved with a def, something like

#input: {
  p1: string
  p2: int
}

foo: {
  inputs: #input
  result: #Def & { inputs }
}

[cueckoo]

Original reply by @nyarly in cuelang/cue#847 (comment)

Here's what I see, though: https://cuelang.org/play/?id=FfoY3gU-1rs#cue@export@cue

IOW, the embedded inputs doesn't see to carry the individual parameters into place.

[cueckoo]

Original reply by @verdverm in cuelang/cue#847 (comment)

you need an extra inputs: { <...> } to make it work as expected

https://cuelang.org/play/?id=V9RZAqZLMZ4#cue@export@cue

[cueckoo]

Original reply by @eonpatapon in cuelang/cue#847 (comment)

For those that don't know what does inherit in nix:

rec {
   foo = 1;
   bar = 2;
   b = { inherit foo bar; };
}

Is just a shorthand for:

rec {
  foo = 1;
  bar = 2;
  b = {
    foo = foo;
    bar = bar;
  };
}

 nix-instantiate --strict --eval test.nix
{ b = { bar = 2; foo = 1; }; bar = 2; foo = 1; }

As scoping rules are not the same than cue, foo = foo will not end up in a cycle error. It could if the b attributeset is defined as recursive (which is a bit like cue standard scoping rules):

rec {
   foo = 1;
   bar = 2;
   b = rec { foo = foo; bar = bar; };
}

 nix-instantiate --strict --eval test.nix
error: infinite recursion encountered, at /home/eon/test.nix:4:20
(use '--show-trace' to show detailed location information)

Using inherit in this case works as there is no self referencing attribute:

rec {
   foo = 1;
   bar = 2;
   b = rec { inherit foo bar; };
}

 nix-instantiate --strict  --eval test.nix
{ b = { bar = 2; foo = 1; }; bar = 2; foo = 1; }

Note that the keyword inherit is quite confusing for new comers.

In the context of cue I have found myself wanting to have a similar functionality when you want to copy a set of fields in a downward struct. Not only in cue you need to repeat the attributes/values you want to duplicate but you need also to avoid cycle errors with aliases or other methods:

{
	Foo=foo: 1
	Bar=bar: 2
	b: {
		foo: Foo
		bar: Bar
	}
}

[cueckoo]

Original reply by @myitcv in cuelang/cue#847 (comment)

Could your example:

{
	Foo=foo: 1
	Bar=bar: 2
	b: {
		foo: Foo
		bar: Bar
	}
}

not be rewritten as:

{
	let x = {
		foo: 1
		bar: 2
	}
	x
	b: {
		x
	}
}

i.e. use let and embedding.

[cueckoo]

Original reply by @eonpatapon in cuelang/cue#847 (comment)

Sure that would work also and is more concise. Maybe a bit more hard to read.

I think with inherit in nix, once you know exactly what it does, it is concise and quite readable. But I am probably biased on that since I'm used to it :)

Anyway I don't know if it would bring a lot of value to have something similar in cue. As you point out there is alternatives for this kind of situations (embedding is not possible in nix).

[cueckoo]

Original reply by @nyarly in cuelang/cue#847 (comment)

The motivating case is something like:

z: {
	let x = {
		foo: int
		bar: int
	}
	x
	b: {
		x
	}
}

w: (z & {foo: 1, bar: 2}).b

If w evaluated to {foo: 1, bar: 2} I'd be happy with this solution, but the let doesn't work as an "anti-embed" here. (Which coinage only comes to mind because Nix calls its string interpolation "anti-quotation").