DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

1. Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
2. Lambda callbacks - Evaluation is handled via callback-style execution.
3. Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

• Should an array input implicitly turn the entire downstream chain into a loop?
• Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

• Enumerate files
• Regex replace
• Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.