Action Language playground

What it is

Canonical Shlaer-Mellor expressed state-action decision logic as Action Data Flow Diagrams — which proved unmanageable in commercial practice. The doctoral methodology kept the SM execution model but replaced the diagrams with a compact XML-based action notation, with a Java compiler/decompiler and a bidirectional execution engine.

The execution engine was designed to operate on the action language model directly, without further compilation. The action language model was treated as if it were the stored program of a Threaded Interpreted Language (TIL) such as Forth.

That detail is worth keeping vivid: Bob’s first commercial language was Forth at Metal Box (1984–89). Twenty-five years later, the doctoral framework’s executable-specification runtime treated the Action Language model as a Forth-style threaded interpreter. The ActionLanguage intermediate representation (IR) in Paradise today is the same shape again. Same execution model, four problem domains, four decades.

How to read the playground

Each worked example below has four panes:

1. XML source— the program text. Editable; press Run to re-execute, Reset to restore the canonical source.
2. Action tree— the parsed action hierarchy. Updates as you type, even before you press Run, so structural errors in the XML surface immediately.
3. Execution trace— every step the engine took, indented by scope. Useful for seeing how recursion unwinds, how variables come into and leave scope, and where each value comes from.
4. Output— what the program printed (in order), plus the top-level return value if the program is an expression.

The engine source is in src/lib/action-language/. No Java is loaded; the engine is a TypeScript port of the original Java reference, running entirely in your browser.

Example 1: Fibonacci

The simplest of the four worked examples. The same example used in the original Action Model Execution Engine appendix to validate the language. Demonstrates function declaration with late-bound constant parameters, conditional expressions, recursion, and the round-trip between XML source and execution trace.

Try increasing the bounds of the print statements (the engine has a recursion-budget guard at 10,000 calls, so the page won’t lock up if you push too far), or replacing the recursive definition with an iterative one to compare the trace shapes.

Loading the Action Language playground…

Example 2: Conditional content selection

The accessibility-shaped if-then-else: pick a presentation metaphor based on a user-capability variable. The point of the example is not the if-then-else itself (mechanically straightforward) but the way the polymorphism lives in the data, not at the call site. The same present(modality)call runs in both cases; the metaphor selection is internal. That is the shape of intrinsic accessibility’s polymorphic task decomposition in microcosm.

Try changing one of the modality strings to "haptic" — neither branch matches, the fallback fires.

Loading the Action Language playground…

Example 3: SM-style state migration

The notification lifecycle from the doctoral framework’s Methodology chapter: Announcing → Dwelling → Expiring → Gone. The notification is the same instance through the transitions; what changes is its subtype, and each subtype renders differently.

In a real Shlaer-Mellor implementation this would use disjoint-complete subtyping with formal role migration. The minimal version here models the state with a string variable and the per-state rendering with an if-cascade — the iteration shape and the behavioural sequence are the same; only the type-system formalism differs. The execution trace shows the migration explicitly: render, advance, render, advance, until the role reaches Gone and the loop terminates.

Loading the Action Language playground…

Example 4: Adaptation across user profiles

A button rollover that adapts its inventory-to-semantics mapping for visual vs sonic user profiles. The same event — USER ENTERS PROXIMITY OF NODE— triggers different concrete realisations through the bridge function on-proximity; the abstract semantic outcome (the button is hover-active) is the same in both cases.

This is the structure the CISNA Adaptation Model is for: an event in the underlying interface gets bridged through to different inventory selections per user-platform, and a single source of truth produces different output. The trace makes the shared semantics visible — both branches return "hover-active" as the abstract result, regardless of which inventory items were selected to produce it.

Loading the Action Language playground…

Reading on

• The Measure of Accessibility — the Shlaer-Mellor lens — the methodological substrate this code makes concrete.
• The CISNA Model — the five-layer architecture that Action Language operates inside.
• Paradise: ActionLanguage IR — the modern descendant in active use for source-level JavaScript accessibility analysis.