Renkon-Pad: A Live and Self-Sustaining Programming Environment Based on Functional Reactive Programming

The need for an end-user programming environment, especially one that allows users to utilize AI models, is stronger than ever. The authors believe that program comprehension by human users will remain important even with AI models involved. This suggests that creating a new environment that is approachable for both humans and AI models will be crucial.

The authors have been working on a local AI project called Project Substrate [3]. Substrate aims to provide hardware and software for running AI models at home. We are exploring ideas around an AI-friendly end-user programming environment, in particular a malleable one where participating AI agents and humans can modify the environment itself dynamically.

(See the footnote¹¹1Since a version of Renkon-pad was submitted and reviewed by the PX/25 committee, there have been new features such as infinite panning and zooming, deactivating a text box, etc. You can find the submitted version here: https://yoshikiohshima.github.io/renkon-pad/px25/ You can also try running Renkon-pad within itself: Open: https://yoshikiohshima.github.io/renkon-pad/px25/?file=https://yoshikiohshima.github.io/renkon-pad/px25/renkon-pad.json in a browser. Once opened, press the “runner” button at the top left, and then press the “play” button at the top left of the created runner window. This should show the embedded Renkon-pad in the runner window. You can also check out the latest development at https://yoshikiohshima.github.io/renkon-pad/. for information on the version in the paper and the latest development.)

Among end-user programming systems, there have been many attempts to provide end-user programming environments with the dataflow execution model and node-and-wire diagram visualization, such as Fabrik, LabView, Blender’s data flow, Natto.dev, and Max/MSP, just to name a few [1][2][4][9]. The node-and-wire diagram works well when the program is relatively small; however, it does not scale well visually for large programs.

On the other hand, the authors believe that the dataflow concept is powerful and scales well for large programs, with favorable characteristics that suit end-users. This is why we are motivated to experiment with the dataflow model again to better understand where the scalability issues arise.

We decided to use Functional Reactive Programming (FRP) as the foundation [7] for the dataflow execution model. The strength of FRP lies in its computation model, which uses an explicit logical time domain, making the program state easier to reason about.

Based on these considerations, the authors created a language called Renkon. A program written in Renkon is a set of reactive expressions, or nodes. The free variables in an expression are used to determine the dependencies among nodes.

The original FRP distinguishes between time-varying variables on a continuous time domain, called “behaviors,” and those on a discrete time domain, called “events.” The value of this distinction is often overlooked in later languages described as reactive, such as Elm and React [5][19], but the authors believe that this distinction is helpful for writing applications, particularly when dealing with graphics and user interactions.

The surface syntax is a subset of JavaScript, but the expressions are connected via free variable references. For example, the following code snippet defines a node and binds it to a variable timer1, and defines another node that has console.log(timer1):

Notice that the variable timer1 is defined on line 1 and used on line 2, creating a dependency relationship between these lines. The Renkon evaluator topologically sorts the nodes based on their dependencies and, during an evaluation step, traverses the sorted list to evaluate nodes as necessary. The definition of the expression bound to timer1 can be changed at runtime, without touching the expression with console.log; it simply picks up the latest value coming from timer1 at runtime, thus making the connection loosely coupled.

The expression Events.timer(1000) updates every 1000 logical milliseconds, causing timer1 to be updated. The second line with console.log executes when the node bound to timer1 is updated. Running this program results in a clock value displayed in the console every second.

While the language is agnostic to any graphics system, a Renkon program running on a web page can manipulate the browser’s DOM. The program can simply manipulate the DOM elements directly, but by using a virtual DOM library such as Preact [18], applications can be structured so that the logic remains in a pure functional style, up to the point of generating virtual DOM elements. These virtual DOM elements can then be rendered to the actual DOM.

We have developed a graphical programming environment called Renkon-pad in Renkon. In Renkon-pad, users can create text boxes to edit the program. A text box can contain any number of node definitions. They can also create separate execution environments called “runners” (in an iframe) to quickly test the program. The code running in a runner can be updated dynamically. Multiple runners can be created within the environment, allowing programs to be run simultaneously. The running application’s data is kept in the runner, enabling updated programs to be tested with pre-existing data.

In the following sections, we will show how Renkon-pad can improve Renkon-pad itself. Despite being a fairly sophisticated application with saving and loading capabilities, the minimum self-sustaining implementation consists of only about 700 lines of Renkon code, including 150 lines of CSS definitions.

We summarize the novelty of our approach below:

• $\mathrm{■}$

  A clean and practical design of the underlying language.

• $\mathrm{■}$

  A set of best practices to effectively utilize the language’s power in application development.

• $\mathrm{■}$

  An architecture for a programming environment that supports live editing and side-by-side comparison of variations.

In the following sections, we provide a more detailed explanation of the Renkon language, describe the implementation of Renkon-pad, two examples created in Renkon-pad, and share our initial experiences using it.

Renkon is an FRP (Functional Reactive Programming) language. The implementation is written in JavaScript so that it can be used in the browser as well as in Node.js. A program in Renkon consists of a set of reactive nodes. Each node reacts to input changes and produces an output. In turn, other nodes that depend on the output value react to it. In other words, the program nodes form an acyclic dependency graph, and changes propagate through it. FRP has an explicit notion of logical time. This means that a node is evaluated at most once at a logical time, even if there are multiple inputs for the node, and computation takes zero logical time.

Renkon’s surface syntax is a subset of JavaScript and TypeScript; most JavaScript syntax is also valid Renkon syntax. The Renkon transpiler takes the node definition and creates a JavaScript expression that evaluates to an internal Renkon node data structure. Care is taken so that an unmodified JS Linter works with a Renkon program (a set of nodes) and spots common errors.

The Renkon transpiler analyzes the definition of a node and notes all external variable references as dependencies. The transpiler works on each node in isolation; a node is completely unaware of what an external reference points to at transpilation time. In other words, the nodes are loosely coupled.

The evaluator topologically sorts the list of nodes based on the dependency relationships. Upon entering a new logical time, the Renkon evaluator walks through the nodes in the list and evaluates them as necessary.

Renkon stands out from other reactive web UI frameworks in three ways:

• $\mathrm{■}$

  Promises and Generators in JavaScript are integrated with the dependency propagation logic.

• $\mathrm{■}$

  Following the original FRP, discrete events and continuous values are separated.

• $\mathrm{■}$

  The definition of reactive nodes can be changed at runtime.

Integrating JavaScript Promises means that the resolved value from a Promise is treated as a value update in Renkon without needing to add await or then. The following hundred is a Promise, but you can change the definition to an expression with a non-Promise value without modifying the rest of the code.

Having the separation between discrete and continuous values provides a way to express the intention of how a value will be used, aiding in writing user interface programs.

Since the nodes are loosely coupled and connected only by their named references, the definition of a node can be dynamically updated independently. For example, the node at line 3 in the above example (the console.log line) only knows that it depends on external nodes named hundred and timer1 but does not know what they are at transpilation time (it also depends on console, but it is treated as a known constant). The definition of timer1, for instance, can be changed from one evaluation step to another, without requiring the node with console.log to be changed. When the value of timer1 changes, either because the timer fires or the definition has changed and the value it produces is different, the console.log line reacts to it in the same manner.

To build a graphical application, the user can directly mutate the DOM elements on the page, but also use a virtual DOM library that treats virtual DOM elements as functional values computed by nodes in Renkon. While Renkon is completely agnostic to such a library, we find that Preact is a good match. An example usage of Preact and Renkon looks like the following:

We import html and render from the standard Preact library. The JavaScript built-in import expression returns a Promise, but the Renkon evaluator handles a promise automatically so that a resolved Promise is treated like any other reactive value. All dependencies that use html, for example, will not be evaluated until the node named html has a value. The html function of Preact processes the DOM tree definition in “Hyperscript Tagged Markup” [12]. When it is followed directly by a backquoted string, it processes the string to return an object – in this case, Preact’s virtual DOM elements.

The render function of Preact calculates the difference between the current actual DOM state and the virtual DOM and updates the actual DOM elements. The second argument for the render function specifies the actual DOM element that will be the parent of the rendered results.

Renkon-pad is a graphical programming environment for editing and running Renkon programs (recall Figure 1). The user can create multiple text boxes (by pressing the “code” button at the top-left) and define any number of Renkon node definitions within each text box. Additionally, the user can create isolated Renkon execution environments called “runners” (in iframes) by pressing the “runner” button.

As described in Section 2, the order of execution is controlled by dependency relationships, meaning that the order of definitions in the program text does not matter. (A historical side note: the Compel language in 1968 had this characteristic [22].) This allows the system to concatenate the contents of text boxes in any order to create a full program.

A runner window has a “run” button at the top-left corner.

When the user presses the run button, the contents of the text boxes are gathered into an array and sent to the embedded iframe using the postMessage mechanism. The receiving iframe has a ProgramState instance that handles the posted message and calls its updateProgram method (see Section 2.5).

The animation frame loop of the iframe in a runner repeatedly invokes the evaluate method of the ProgramState to run the program.

We show two examples created in Renkon-pad. Each example illustrates some interesting aspects of the language and Renkon-pad.

There have been numerous attempts to create programming environments, particularly those based on dataflow and node-and-wire diagrams. The lineage of such environments can be traced back to Bert Sutherland’s graphical language [20].

Some past dataflow environments, such as Fabrik, successfully implemented a programming tool similar to the Smalltalk code browser within a node-and-wire dataflow editor. However, Fabrik did not attempt to create the node-and-wire editor within itself.

RecipeSheet [10] leans toward providing “side-by-side” comparisons of results from running different “recipes” or program scripts. The number of nodes used in this environment is typically small.

Natto.dev introduced a 2D zoomable canvas where users can create code nodes connected with wires to represent dataflow. It allows nodes to be connected by referencing names, similar to Renkon-pad. However, Natto encourages users to create boxes on the screen to represent individual computation nodes, which suffer from the scalability issues common to traditional node-and-wire diagrams. Additionally, its implementation was not done within Natto.dev itself.

Vivide [21] is a feature-rich environment designed for quick data exploration. It is based on pipelining transformation functions. However, to the authors’ knowledge, Vivide does not model the environment within itself.

KScript and KSWorld are FRP-based graphical frameworks developed by one of the authors [15]. They successfully implemented a “universal document editor,” which combined spreadsheet, document editing, and presentation capabilities within the FRP paradigm. However, the scope was slightly more ambitious; the layout algorithm involved constraints, which are inherently multi-directional. This affected the properties of graphical elements, making the editor prone to inconsistencies in evaluation (which are technically called “glitches” in the FRP community).

The implementation strategy for FRP in Renkon closely resembles the KScript language used in the KSWorld framework. In KSWorld, changing the display tree structure (e.g., adding or removing a graphical object) altered the number of FRP nodes in the system, requiring the dependency graph to be re-sorted dynamically. This complexity, in conjunction with the attempt to accommodate multi-directional relationships, made KSWorld less practical.

In contrast, Renkon-based applications tend to offload actual visual rendering and layout processing to the browser. This comes at the cost of being unable to react to layout changes created by CSS. While this limitation could be restrictive in some cases, it seems to be a reasonable trade-off for practical applications.

In this section, we discuss the lessons learned from designing the Renkon language and environment.

Using a virtual DOM while adhering to functional values means that an object like the CodeMirror text editor cannot directly participate in the reactive dependency network. That is, we cannot store a Renkon node inside CodeMirror and expect a Renkon event to fire upon an edit. This design choice appears reasonable, but in some cases, we may need to bend the rules to accommodate such external entities.

As discussed in Section 2.4, there are mechanisms to handle cyclic dependencies, such as $-variables or Events.send. However, these mechanisms can subtly break consistency if the program uses an event that triggers Events.send at the “current” logical time. Those features must be used carefully, as they remain a potential source of glitches.

Any glitch requires considerable debugging effort. While it is possible to build a dataflow engine or event-based framework without FRP or another formally structured foundation, we believe a strong theoretical foundation is crucial, even at the cost of some flexibility.

We chose JavaScript syntax primarily for pragmatic reasons. This allows us to leverage the browser’s developer console features with minimal effort and to use existing linters for Renkon code. For example, we add the “sourceURL” annotation to the transpiled code, which enables the browser to display the code in the Sources tab. You can use typical developer console features, such as setting a breakpoint.

In the long run, however, we can envision a better language designed from the ground up. At the very least, if the language allowed the definition of objects like Point and Rectangle with operator overloading, many parts of applications could be written in a more intention-revealing manner.

When integrating Promises into an FRP language, we faced the question of whether the resolved value should be treated as an event or a behavior by default. There seems to be no single correct answer. If a Promise results from an import expression, the value should be retained as a continuous value. However, if the Promise is returned from an async generator, it is more likely to trigger discrete actions rather than persist. Currently, Promises are treated as behaviors, except when returned from a generator. We may revisit this decision in the future.

The equality check described in Section 2.2 is simple and straightforward. However, when using a Map or mutable object, the programmer must wrap the Map to ensure the equality check fails when expected. One possible improvement would be a custom Map class where the set method increments a hidden counter, allowing equality checks to track updates. However, we believe that keeping the underlying mechanism simple and relying on programmer discipline is a reasonable trade-off.

Notably, using Map as a state in the popular React framework often leads to challenges in triggering recomputation and re-rendering of nested components. In contrast, the combination of Renkon and Preact works well for common patterns that involve using Map as a data structure.

The performance of applications written in Renkon is good. Renkon-pad runs at the regular frame rate (120FPS) on a modest laptop computer, even when there are hundreds of windows with CodeMirror editors, even when dragging a window quickly. When Preact virtual DOM becomes a performance bottleneck, a Renkon program can directly update DOM properties without going through the virtual DOM mechanism if necessary. Additionally, the “signal” mechanism [6] may be incorporated. There are some opportunities for tuning larger applications.

Renkon has a feature to create a “component” in terms of a new ProgramState. The new ProgramState has input node names and output node names. The user of the subgraph can instantiate a component by calling it in the following form:

These three lines mean that component is a function that creates a sub-ProgramState, and when an input (in this example, a) changes, the graph is triggered, and the output object with output values updates accordingly.

We did not use the component feature for Renkon-pad, but for building different organizations of applications, this feature is useful.

One of the authors has worked on multi-user application frameworks that were live-programmable, based on Croquet [14, 16]. While we have not yet created a multiplayer Renkon application, past work on TBAG [8] and Croquet suggests that the event-based abstraction and model-view separation concepts align well with the FRP model. For example, as long as values stored in the data structure are strictly serializable, the system could infer appropriate Croquet API calls automatically, eliminating the need for boilerplate code. This presents an intriguing direction for future work.

While Renkon supports TypeScript, we have not yet fully implemented support for tools such as an ESLint plugin and other development helpers. FRP is inherently suited to strict type checking, and the distinction between events and behaviors should ideally be enforced statically by the type checker. Enhancing the editing experience is part of our future development plans.

We have implemented an FRP-based language called Renkon and a graphical programming environment that supports live programming and side-by-side comparisons for program exploration. Notably, the environment is powerful enough to modify and improve itself.

The authors thank Ted Kaehler and John Maloney for their valuable suggestions on the early version of the paper. The authors also thank the reviewers for their insightful and thorough comments and suggestions.