The graph runtime combines declarative scalar value graphs with explicitly ordered effects. Proven pure scalar calculations can share results within an execution activation, while calls, mutations, and I/O preserve their execution order. A function call still executes when its return value is unused—it might be changing state elsewhere.
Literals such as integers, floats, strings, and booleans become static leaf nodes. More complex expressions depend on other nodes. Branches and loop gates are represented in the graph, and traversal determines which paths execute. Assignments capture values; they do not create automatically updating formulas. Expressions are explicit components of the runtime representation, although BLBX does not currently expose arbitrary expression graphs as values that source programs can manipulate.
This started because I wanted to explore a question: What happens if you design a language around the structure of computation, with control flow participating in that structure?
Graph representations are common in compilers and interpreters. My interest is in using the graph directly as the execution model and exploring how value dependencies interact with ordered effects. BLBX is still evolving. I’m particularly interested in where this approach leads with functions, objects, dependency tracking, optimization, and potentially parallel execution. The current backend is conservative: it does not assume user-defined functions are pure, and it does not provide a general parallel graph scheduler.
I’ve also been using BLBX for larger experiments, including writing a chess engine in the language. I’m not claiming graph execution replaces conventional runtimes. BLBX is an experiment in what this model makes possible and what tradeoffs it introduces.
I’d especially appreciate feedback from people who have worked on compilers, interpreters, dataflow systems, or programming-language design.