The D4rt Interpreter is where Tom runs and generates Dart code at runtime, inside a permission-guarded sandbox, without ahead-of-time compilation. It is the engine beneath Tom's AI scripting, the application-creation flow, and the agentic UI that renders live inside a Flutter client — one of the seven building blocks of the framework, and the most mature of them: tom_d4rt is at release 1.229 and every library package of the family is published on pub.dev.

The core problem D4rt solves is that a framework which lets AI and users write code that the application then executes cannot ship a Dart compiler, and must never let untrusted code touch the host freely. D4rt answers both halves: it interprets Dart source directly, and it does so in an isolated scope where sensitive operations — file system, processes, network, isolates — are blocked by default and granted only through an explicit, fine-grained permission API (grant()). The lineage is openly credited: tom_d4rt is an extended clone of the original d4rt interpreter by Moustapha Kodjo Amadou (2025), on whose design the whole family is built.

Two interpreter lines, one bridge API

D4rt is not a single interpreter but a family, organised around one shared bridge API so that native Dart code can be exposed to scripts the same way regardless of which interpreter runs them.

• The analyzer-based line is the released reference implementation. It builds

on the Dart analyzer package to get a full parse tree, then walks it in two passes — a declaration pass (registering classes and mixins) followed by an interpretation pass (resolving members and calling the entry point). It supports both full-script execution (execute()) and REPL-style incremental evaluation (eval(), which keeps the previous scope alive). This is the stable line every existing project depends on, and — because it parses source directly — the usually preferable choice for command-line, server, and desktop embeddings. - The analyzer-free line exists because the Dart analyzer is large and tree-shaking-hostile, so it cannot ship inside a deployed app (especially on the web). tom_d4rt itself makes no web platform claim — it depends on analyzer and dart:io. This line parses source on a build machine into a serializable AST bundle and interprets that bundle on-device, so the analyzer never travels with the application — which is also what unlocks over-the-air UI updates. Its bridge API is kept in 1:1 lockstep with the analyzer-based line, so generated bridges run unchanged against either interpreter. Because the AST bundles it consumes are comparatively large, it is best understood as a complete alternative for the web/OTA case, not a drop-in default.

The components and modules

The area is delivered by the D4rt component (d4rt) and its twelve modules, plus a runnable sample corpus.

Analyzer-based foundation

• tom_d4rt — the sandboxed, analyzer-based interpreter and runtime; the

reference implementation the rest of the family tracks. Its public API (D4rt, BridgedClass, D4, the permission classes) is held in lockstep with the analyzer-free successor so bridges work against either. The sandbox gates the working directory and process execution as well as files, network, and isolates: a process starts only when a ProcessRunPermission covers the command or a filesystem grant carries execute for the executable. A module exports only its own declarations and its exports — an importer never sees an import's imports. - tom_d4rt_flutter — the source-based interpreter with the full Flutter Material bridge surface (SourceFlutterD4rt): feed it raw Dart source and it returns a live Widget. It is the primary, recommended way to run interpreted Dart UI on Flutter for desktop and mobile.

Analyzer-free line (parse on build, run on device)

• tom_ast_model — a zero-dependency, serializable Dart AST model: a complete

S-prefixed mirror of the analyzer's node hierarchy with JSON round-tripping and structural diffing. It is the wire format the analyzer-free line passes from build machine to device, versioned independently of any execution engine. - tom_ast_generator — the 1:1 AstConverter that walks an analyzer CompilationUnit and emits the structurally identical SAstNode tree, plus the bundling machinery for the parse-once / interpret-without-analyzer workflow. - tom_d4rt_ast — the analyzer-free interpreter runtime that executes pre-compiled SAstNode bundles directly, with full bridging, sandboxing, and standard-library support and no analyzer present. - tom_d4rt_exec — the analyzer-free build/CLI entry point: it parses source with the analyzer, mirrors it into the tom_d4rt_ast tree (or an AstBundle), and hands it to the runtime — separating parsing from execution. - tom_d4rt_flutter_ast — the analyzer-free Flutter Material bridge, for live widgets rendered from an AstBundle with no analyzer on device. This is the right choice for web targets and over-the-air UI updates.

Code generation

• tom_d4rt_generator — the bridge generator: it reads a d4rtgen: block in

buildkit.yaml, follows barrel exports, and emits the *.b.dart files that register native Dart APIs with the interpreter so scripts can call them. (This is the bridge generator referenced across the framework's code-generation story; it lives here, in its home component.)

REPLs and shell tooling

• tom_d4rt_dcli — the analyzer-based REPL/CLI nucleus: it sits on tom_d4rt

and adds dcli shell bridges, VS Code scripting-API and chat bridges, an abstract D4rtReplBase, and a ready-to-run dcli executable that downstream tools extend. - tom_dcli_exec — the analyzer-free counterpart, built on tom_d4rt_exec: the same DCli-equipped, extensible REPL base (with a cli global inside every script) for the analyzer-free line.

Samples, test and example apps

• tom_d4rt_samples — five runnable, self-contained samples ordered as a

learning path, each introducing one capability on top of the last: multi-file D4rt programs and shebang launchers (d4rt_introduction_sample, start here), bridging a native library through tom_d4rt_generator (d4rt_advanced_sample), hand-written user-bridge overrides (d4rt_userbridges_sample), shell scripting through the dcli REPL (d4rt_dcli_sample), and interpreting a live Flutter UI from source (d4rt_flutter_sample).

• tom_d4rt_flutter_test / tom_d4rt_flutter_ast_test — the working

test/demo apps for the two Flutter bridges: the first exercises the source-based tom_d4rt_flutter over a 37-app sample corpus (with script playback and an AI-assisted UI generator), the second loads 33 of those samples as pre-compiled AstBundles through the analyzer-free, web-safe tom_d4rt_flutter_ast — the same UIs across both lines.

How it fits the rest of Tom

D4rt is the dynamic-execution substrate for the rest of the framework. In the creation flow, both tom_flow (the flow engine) and tom_brain (the AI cognition) use D4rt to execute the dynamic code they produce or script. In the agentic line, a server can expose tom_brain as a service that generates agent surfaces which run inside the Flutter client via tom_d4rt_flutter — the interpreter rendering live widgets from code that did not exist at compile time.

Because the analyzer-based and analyzer-free lines share one bridge API, a capability written once — a bridged library, a generated proxy — is available to scripts whether they run in a desktop tool with the analyzer present or in a shipped mobile/web app where it is not. That single-API design is what lets D4rt be both a developer REPL and an in-app runtime at the same time.