(This part is extremely speculative. It's beginning to use Starlark as an example of what we might want to see in an "L3+" system. The goal in this doc isn't necessarily working stuff or committing to details, it's just to dream about what good composition would look like.)

((UPDATE: Work started on https://github.com/ipld/go-datalark — this should provide a very useful binding library that, combined with our existing schemas, should make massive amounts of things “just work”.)

Considerations

• We probably ought to be able to see how a programmatic ‣ library could be formed here.
• Remember to try to solve for understand user story for generating inputs based on proglang with this — ingesting someone else's things probably needs a tool that's "templated" somehow, which means we should be able to see it up here, probably.

Larksnips

(A working title for "a snippet of starlark which patches a warpforge plot document".)

Traits of a good Larksnip

A good larksnip should be applicable to a plot as a patch, and it should be commutative with other well-behaved larksnips.

In essense, that is always reached if it's a patch that A) doesn't look at what it's about to patch (!) and thereby doesn't change behavior based on what's come before and B) doesn't collide with anything.

(That Part B criteria would be really tricky... if we didn't have content-addressing providing a natural conflict avoidance mechanism. But we do have it! Sweet.)

What about things that don't fit that model?

How should one deal with noncommutable things?

For example, $PATH. Appending path — like any string append — is not commutative. It's order sensitive.

Okay, then there are two options: