Code generation with cue

[myitcv]

Originally posted in Slack by @eadlam:

I’ve been exploring code generation with cue for the last 6 months. I’ve built a configuration system which defines types in cue and exports those types to capnp. Then I refine those types to fully specified configs which I materialize to json. The generated capnp cpp classes can then load the json.My code generation pipeline is cue->openapi->capnp->cpp. I generate the capnp specs from openapi using Python.In general, I think the ability to represent the cue AST in json is extremely valuable, as it provides a language agnostic interface for code generation.Since OpenAPI is not fully capable of representing the cue AST, I think it would be great to move forward with generating a cue-specific json schema.My next project is to model a whole system in cue and generate state machines and potentially TLA+ code from that model. I believe cue can model systems to the same degree that SysML can, and may provide a viable code-first approach to model based software engineering. A fully compatible json schema would be a huge enabler for this effort.

---

Response from @mpvl:

Open to proposals how that would look like.

---

Response from @myitcv:

@eadlam is the AST by itself a sufficient interface for code generation? My suspicion is that it would not be.

---

Response from @eadlam:

With the current OpenAPI export, I have access to types and partially specified dependent types. With that I believe I can generate hierarchical state machine scaffolding, including states, event types, simple guard functions, pre/post conditions and at least the method signature for more complex action/guard functions.

Although that still leaves the action/guard functions for developers to implement, it’s still a sizable chunk of executable code which also happens to be at the same level of abstraction one needs for model checking.

The remaining actions/guards that the developer implements would be simple functions that take a mutable state object and immutable event object, and update the state in some way. Cue’s partially specified types can then be used to generate tests that the state properties remain within correct bounds.

As I said, I think the OpenAPI spec is actually sufficient to do all this. I imagine I could do more with the AST, but I don’t know that for sure.

I guess there are really two separate things that I'm interested in:

1. Schema definitions exported to regular json schema if this would allow us to provide more detail than what we currently get with OpenAPI. I thought I remembered @marcel van Lohuizen saying that cue can't be completely mapped to OpenAPI, but I don't know if json schema itself provides a way around that
2. The type/value lattice in some json format

[cueckoo]

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

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