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

[verdverm]

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).

[myitcv]

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)

[myitcv]

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.

[verdverm]

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.

[verdverm]

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

[myitcv]

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?

[verdverm]

It looks very much like #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

[cueckoo]

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

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