Functions

A fn is a named stretch of graph that other graphs can run. Fn declares one and holds its parameters, Fn Return ends it and hands back results, and Call Fn invokes it and waits for the answer. Three nodes, one purpose: stop copying the same eight nodes into every widget that needs them.

Conventions

• All three nodes belong to event graphs. A fn body is not a function graph. function is a separate graph kind — entered by Function Entry, no effectful nodes, no latent nodes — while a fn body is ordinary event-graph territory and may do anything an event graph may do.
• A fn is identified by its head node, not by its name. Rename it on the card and every caller re-labels itself without breaking. Two fns sharing a name in one scope still resolve correctly, and the editor flags the collision, because the name is for you and the binding is by id.
• Visibility follows the owner. A fn declared on a globalMain blueprint is callable everywhere. One declared on a surfaceMain or widgetMain blueprint is callable only from the same Surface. A Blueprint Value can call but never declare; componentWidgetMain and sharedAsset blueprints do neither.
• Parameter and result pins are authored, not fixed. Fn and Fn Return grow their data pins from buttons on the card, and each pin carries a name and a type chosen from string, integer, float, boolean, json, or any.
• Recursion is capped at 32 frames. Past that the call fails outright. The editor warns as soon as it can see that a fn calls itself, directly or through another fn.

Fn

blueprint.fn.head

The head of a callable fn. It has no exec input — nothing in the graph wires into it; it starts running because someone called it, and the body hangs off then.

On-card fields

Add parameter appends one data output pin per parameter (param_N_value), each with the label and type you set on the card. Arguments are seeded before the body starts, so the parameter pins already hold the caller's values at the first node of the body.

Fn Return

blueprint.fn.return

Ends the fn body and hands its results back. Terminal — there is no exec output, and nothing after it runs.

Add return value appends one data input pin per result (ret_N_value). Result pins never offer an on-card literal: a result must come from a wired value source, so the graph always shows where the returned value was produced.

A fn's signature is taken from the first Fn Return reachable from the head. Further Fn Return nodes on other branches are fine as long as they declare the same results — declare different ones and the editor flags them, while callers keep seeing the first one's pins. A Fn Return that no head can reach is flagged too.

Call Fn

blueprint.fn.call · Latent

Invokes a visible fn and waits for it to finish. Pick the target in Function and the card grows one data input per parameter and one data output per result.

On-card fields

Those argument and result pins are rebuilt from a signature snapshot stored on the node itself, so the card can render without loading the callee's blueprint. Argument pins accept on-card literals where the type allows it. When the callee's signature changes, the snapshot goes stale and validation asks you to re-select the fn to resync the pins — the call keeps working against the old shape until you do.

The body runs as part of the caller's execution: cancelling the caller cancels the fn, and an error thrown inside the body surfaces on the Call Fn node.