Tips, Tricks, & Style: Cue

[salotz]

I wanted to share some very important "tricks" I'm coming across when working with Cue. Of course we can defer to that project but I think it would be beneficial to have some that are especially helpful in the context of Timoni.

I'll start off with this page in their docs: https://cuelang.org/docs/concept/alias-and-reference-scopes/

This was a very confusing error to get so I'm glad I found this!

The problem is that to implement modularity in Cue you kind of have this pattern that roughly approximates a function call:

#SubThing: {
    // This is the "argument" to the function
    #config: #Config

    stuff: #config.name    
}

#Thing: {
    #thisConfig: #Config
    subthing: #SubThing & {
        #config: #thisConfig
    }
}

#Config: {
	name: string
}

// export...
#Thing & {
	#config: {
		name: "Bob"
	}
}

This looks like it should work but instead you get this error:

$ cue export functions/thing.cue
subthing.stuff: incomplete value string:
    ./functions/thing.cue:16:8

Furthermore you have this problem where the names of the arguments conflict. #thisConfig shouldn't have to be distinguished from the inner #config of #SubThing. At least coming from function based languages this kind of a basic primitive.

The solution is aliases:

#SubThing: {
    // This is the "argument" to the function
    config=#config: #Config

    stuff: config.name    
}

#Thing: {
    config=#config: #Config
    subthing: #SubThing & {
        #config: config
    }
}

#Config: {
	name: string
}

// export...
#Thing & {
	#config: {
		name: "Bob"
	}
}

Visually this also kind of distinguishes definitions that aren't part of the "arguments" and solves all the above problems.

This also shows a little style thing to distinguish abstract and concrete definitions using the first capitalization. Lower for concrete and capital for abstract "types".

What I don't quite understand is whether #config should just be a hidden key like _config. It seems to me that one of the reasons I am using a definition is to stop it from being exported. I.e. separating the return values from the inputs and "stack" variables.

Thoughts? Improvements I can make?

[stefanprodan]

What I don't quite understand is whether #config should just be a hidden key like _config.

We've hit a CUE bug doing so, using definitions to pass inputs is the right way to do it. For context see:

• Nested packages in templates is difficult #273
• Change the config type to definition #302

[salotz]

I don't think it was conclusive that the hidden field was the issue though. I had similar issues with using the definition (re: that article on the new cuelang docs).

[salotz]

I think I found part of my answer here in the language reference on struct closure

A closed struct c is a struct whose instances may not declare any field with a name that does not match the name of a field or the pattern of a pattern constraint defined in c. Hidden fields are excluded from this limitation.

So a hidden fields are really only meant for internal reference in a struct, e.g. intermediate values. I had only understood that hidden fields influence the struct generation/outputs and not the inputs as well.

I guess that is useful because you can unify something and add your own hidden fields for intermediate values not supported already.

So definitions as "arguments" is the only remaining option since it can be referenced externally and doesn't influence what the return values would be, since a non-definition value would have to be exported.