User Interfaces and Visualization

User interfaces and visualization

MLPL separates the program from the surface that presents it. The same language can run in a terminal, in a browser through WebAssembly, behind a native server, or inside a native host. Visualization results can be rendered inline, stored as artifacts, or interpreted by an extension-owned application.

At a glance

Option	Where evaluation runs	Presentation	Best suited to
Native CLI REPL	Local native process	Interactive terminal transcript	Exploration with files, full evaluator coverage, traces, and optional local accelerators
Native script	Local native process	Terminal, files, or stored artifacts	Repeatable programs, batch jobs, demos, and automation
Compiled binary	Standalone native process	Whatever stdout, files, or host integration the supported program uses	Deployment without shipping the parser or interpreter
Browser playground	Browser WASM	REPL/editor UI and inline SVG, HTML, and 3-D views	Zero-install learning, demos, and small experiments
Connected browser	mlpl-serve on a native host	Browser UI, streamed telemetry, and fetched artifacts	Browser ergonomics with native files, persistent sessions, CPU, MLX, or CUDA
Connected terminal	mlpl-serve on a native host	Terminal client and streamed results	Remote or shared native computation without a browser
Native extension application	MLPL evaluator plus a native host/provider	Retained native scenes, windows, input events, or another host-defined UI	Interactive applications whose platform UI should remain outside the core language

These are presentation and deployment choices, not different MLPL dialects. Backend availability still depends on the build, host, and operation; see Execution Surfaces and the Capability Matrix.

CLI: REPL and scripts

mlpl-repl provides the broad interactive command-line surface. It retains workspace state, exposes inspection commands, runs files, and can use sandboxed native file access, tracing, experiment storage, and supported CPU/GPU paths. Script mode runs a repeatable .mlpl program from a chosen source directory.

cd sw-mlpl/components/cli
cargo run -p mlpl-repl
cargo run --release -p mlpl-repl -- -f ../../demos/tiny_lm.mlpl

Terminal output is appropriate for values, tables, progress, diagnostics, and automation. Visualizations are normally written as artifacts rather than rendered directly in the terminal. A CLI can also connect to mlpl-serve, moving evaluation and session state to another machine while retaining a terminal interface.

Native binaries

mlpl build lowers the supported language subset to Rust and then to a native executable. The resulting program does not carry the MLPL parser or interpreter. This is a deployment surface rather than a separate UI: a compiled program may use stdout, binary streams, files, or host integration according to the features supported by the compiler path.

The interpreter covers more of the language, so confirm each required construct against the repository compiler guide and compiler coverage report. See Native CPU for the wiki overview.

SVG, HTML, images, and dataflow diagrams

MLPL visualization operations produce structured visualization values rather than assuming one display device. The rendering layer supports ordinary charts, heatmaps, decision boundaries, model diagrams, animations, specialized ML views, 3-D presentations, and structural dataflow diagrams.

• In the browser, supported SVG, HTML, and 3-D results render inline beside the transcript or demo narration.
• Native CLI and server execution can store visualization artifacts instead of dumping markup into terminal output.
• mlpl-serve stores content-addressed SVG, HTML, PNG, JPEG, and JSON artifacts for connected clients to retrieve.
• dataflow(nodes, edges) produces SVG diagrams with grouping bands, quantitative edge widths, highlights, recurrence back-edges, and label-aware spacing.

SVG is especially useful for inspectable diagrams and static publishing. HTML or browser 3-D renderers are appropriate where interaction matters. Raster artifacts are useful for external reports and tools. See the source repository's visualization IR for the boundary between evaluator results and renderers.

Browser and WASM

The hosted playground combines an MLPL REPL/editor, demo picker, tutorials, glossary, narration, and inline visualization. In browser-only mode the evaluator runs locally as WebAssembly and keeps state in browser memory. This makes the surface portable and installation-free, but it cannot directly open arbitrary local files, spawn processes, load native libraries, or link MLX/CUDA.

The editor and REPL are two views over the browser learning environment: editor mode is useful for a complete program, while the REPL emphasizes incremental evaluation and inspection. Loading or running a demo presents its explanatory material and results through the REPL-oriented view.

See Browser and WASM for the execution flow and sandbox boundaries.

Connected browser and stored artifacts

Connected mode keeps the same browser interface but sends evaluation to mlpl-serve. The server owns authenticated, persistent sessions and may have native filesystem access or CPU, MLX, and CUDA support. The browser streams telemetry, retrieves stored visualizations, and enables demos according to the devices reported by the server.

This is the usual choice when a browser is the desired UI but the workload or data belongs on a native workstation or remote accelerator. See Server and Remote Execution for topology, persistence, cancellation, CORS, and authentication.

Native graphics and extension-owned applications

Native graphics are intentionally an extension/host concern rather than a windowing toolkit built into the MLPL evaluator. The native extension boundary can exchange scalars, dense arrays, nested records, and opaque handles. Ports and bounded event delivery allow a host-owned application loop to deliver input and lifecycle events while MLPL owns domain logic, scene construction, and state transitions.

The demo-extensions repository is the executable reference. It includes retained line/point scenes, stable-ID scene patches, camera and view updates, and interactive examples such as a wireframe cube, tic-tac-toe, Life, and an ML microscope. Those demonstrations prove an extensible route to native windows and application loops; they do not make a particular graphics framework part of the portable core language or the browser/WASM surface.

Choosing a surface

• Start with the browser playground when installation-free learning and inline visuals matter most.
• Use the native REPL for the broad evaluator, local files, inspection, and interactive development.
• Use scripts for repeatable command-line workflows and artifact generation.
• Compile the supported subset when the deliverable should be a standalone native executable.
• Use a connected browser when the UI belongs in the browser but evaluation belongs on a native or GPU host.
• Use native extensions when the application needs native graphics, device APIs, persistent host objects, or a platform event loop.