Is there a meaningful semantic difference between conjuncted and embedded definitions when nested inside another definition?

[cueckoo]

Originally opened by @verdverm in cuelang/cue#845

Given the following, is there a meaningful difference from preventing incorrect values or extra fields w.r.t. the n field?

#SchemaNested: {
  s: string
}

#SchemaConj: {
  n: #SchemaNested
}

#SchemaEmbd: {
  n: { #SchemaNested }
}

#SchemaInline: {
  n: a: string
}

A: #SchemaConj: {
  n: a: "A"
}

B: #SchemaEmbd & {
  n: a: "A"
}

C: #SchemaInline & {
  n: a: "A"
}

They seem to be enforcing the same constraints. I suspect that the outer definition closes the innerards so I get an equivalent outcome. Inline is less ideal because we'd like to capture some common schema.

The context of this question is using Embed as a temporary and "correct enough" work around for the TBD Structural Sharing that is causing significant runtime increase with series of nested Conjuncts (i.e. #SchemaConj pattern repeated for multiple nesting levels).

[cueckoo]

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

Referencing a definition recursively closes it (spec).

Embedding a definition (which involves referencing a definition) disregards closedness for the purposes of embedding, but the enclosing struct is recursively closed as a result (spec).

As written, there is no difference however.

The context of this question is using Embed as a temporary and "correct enough" work around for the TBD Structural Sharing that is causing significant runtime increase with series of nested Conjuncts (i.e. #SchemaConj pattern repeated for multiple nesting levels).

Please can you raise an issue for any problem you are seeing? I'm not aware of what you are referring to specifically (and we should have issues tracking these sorts of things)

[cueckoo]

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

I'm not clear why or whether embedding is a workaround for structural sharing - you are still referring to the same definition, indeed you're likely doing at least as much work because a new context of closedness is established. But @mpvl will be able to confirm.

[cueckoo]

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

Our testing shows a significant reduction in runtime, or increase if we like. It looks exponential.

I suspect the embedding avoids the conjunct explosion from Billion Laughs style nested references to conjuncts.

[cueckoo]

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

We get about the same performance difference with the #SchemaInline and the #SchemaEmbed, with the latter preserving the schema fragments for post structural sharing

[cueckoo]

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

Just to confirm, @verdverm - you're seeing n: { #SchemaNested } be faster than n: #SchemaNested?

If so, we should investigate that. Because strictly speaking the former has more work to do than the latter.

That might point to an optimisation being left on the table somewhere, or more likely an issue.

Please can you raise an issue with a repro that shows the timing difference?

[cueckoo]

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

It looks very much like cuelang/cue#803 but with more nesting and conjuncts, The temp workaround for include only worked so far it appears. I suspect the same conjunct-copy is at play. This also has the same x: base & output differences you noted there