You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The value/port type system currently requires each input or output field to be a single Value type (one x-value-type, or a generic with a single inner Value). There is no way to declare a port that accepts one of several value types.
This blocks clean designs elsewhere. Concretely, in #153 (more arithmetic nodes) we want a single variadic node to also accept a sequence — i.e. a param/input typed FloatValue | SequenceValue[FloatValue] — so that Add/Multiply/Min/Max subsume their Sum/Product sequence counterparts instead of shipping two nodes per operation. Without unions we're forced to duplicate (variadic node + sequence node) for every associative op.
What's needed
A union value type usable anywhere a Value type is expected:
Schema representation — how a union is expressed in the compact x-value-type form and the expanded JSON Schema (likely an anyOf / oneOf of x-value-type entries). schema parse/check must understand it.
Validation — a value validates against the union if it validates against any member.
Edge type-checking — a source is assignable to a union target if it's assignable (directly or via a registered cast) to any member. possible-edges and add-edge must account for this.
Casting interaction — define precedence when a source could cast to more than one union member (e.g. prefer exact-type match, then first castable member).
Runtime — node run receives whichever concrete Value matched; nodes branch on the concrete type.
Open questions
Tagged vs untagged union (do we need a discriminator, or is structural matching enough)?
Interaction with the existing cast registry — does a union target widen the set of acceptable sources too aggressively?
Serialization stability across versions / migrations.
Blocks
Add more built-in arithmetic nodes #153 (arithmetic nodes) — the "variadic vs sequence vs both" decision collapses to "just variadic, with a FloatValue | SequenceValue[FloatValue] input" once unions exist.
Motivation
The value/port type system currently requires each input or output field to be a single
Valuetype (onex-value-type, or a generic with a single innerValue). There is no way to declare a port that accepts one of several value types.This blocks clean designs elsewhere. Concretely, in #153 (more arithmetic nodes) we want a single variadic node to also accept a sequence — i.e. a param/input typed
FloatValue | SequenceValue[FloatValue]— so thatAdd/Multiply/Min/Maxsubsume theirSum/Productsequence counterparts instead of shipping two nodes per operation. Without unions we're forced to duplicate (variadic node + sequence node) for every associative op.What's needed
A union value type usable anywhere a
Valuetype is expected:x-value-typeform and the expanded JSON Schema (likely ananyOf/oneOfofx-value-typeentries).schema parse/checkmust understand it.possible-edgesandadd-edgemust account for this.runreceives whichever concreteValuematched; nodes branch on the concrete type.Open questions
Blocks
FloatValue | SequenceValue[FloatValue]input" once unions exist.