BLBX is a dynamically typed, multi-paradigm language exploring how control flow and expressions can fit into a shared computational model. It combines functional-style syntax, callback-based control flow, and object-oriented features. Its experimental Black Box backend represents computation as a traversable execution graph. After parsing and lowering through an intermediate representation, functions, conditionals, loops, assignments, and ordinary expressions become explicit graph components. BLBX also retains its original interpreter as a separate execution option.

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.