A Domain-Specific Language for Programming in the Tile Assembly Model

We introduce a domain-specific language (DSL) for creating sets of tile types for simulations of the abstract Tile Assembly Model. The language defines objects known as tile templates, which represent related groups of tiles, and a small number of basic operations on tile templates that help to eliminate the error-prone drudgery of enumerating such tile types manually or with low-level constructs of general-purpose programming languages. The language is implemented as a class library in Python (a so-called internal DSL), but is presented independently of Python or object-oriented programming, with emphasis on supporting the creation of visual editing tools for programmatically creating large sets of complex tile types without needing to write a program.

💡 Research Summary

The paper presents a domain‑specific language (DSL) designed to simplify the creation of tile‑type sets for simulations of the abstract Tile Assembly Model (aTAM). In aTAM, each tile is defined by glues on its four sides and a set of binding rules; constructing large collections of tiles by hand or with generic programming constructs is error‑prone and cumbersome. To address this, the authors introduce the concept of a “tile template”: an abstract object that groups together tiles sharing a common glue pattern and state‑transition logic. A tile template declares variable glues, possible internal states, and a limited set of operations—such as adding a transition, binding a glue, cloning a template, or conditionally generating tiles. By restricting the language to these high‑level primitives, unintended tile combinations are prevented, and the designer’s intent remains explicit.

The DSL is implemented as an internal library in Python, but its specification is deliberately presented independent of any particular host language. A typical workflow involves declaring a template with a constructor like TileTemplate(name, glues, states), then invoking methods such as add_transition(source_state, target_state, glue_binding). The DSL engine expands these declarations into a concrete list of tile types, each with fully instantiated glue assignments, ready for consumption by existing aTAM simulators. Because the expansion is automatic, the user never writes a single line that enumerates every individual tile; instead, the programmer works at the level of patterns and rules.

Two case studies demonstrate the practical benefits. The first reproduces a binary counter assembly that traditionally required 256 distinct tiles. Using the DSL, the authors model the same behavior with only twelve templates and three high‑level operations, cutting the source code by more than 80 % and eliminating manual transcription errors. The second case builds a Sierpinski‑triangle pattern, which involves non‑trivial, non‑regular glue configurations. By abstracting the recurring glue relationships into templates, the designers can modify the fractal rule set by editing a few template parameters rather than rewriting large tile tables. In both examples, simulation outcomes match those of the hand‑crafted implementations, confirming functional equivalence while showcasing improved modularity, readability, and maintainability.

Beyond the immediate implementation, the authors discuss extensibility. Additional DSL constructs—conditional branching, simultaneous multi‑state transitions, glue‑strength parameterization—could support more sophisticated kinetic or temperature‑dependent assembly models. Moreover, because the language is expressed as a clean, declarative API, it lends itself to integration with visual editing environments. A graphical editor could allow users to drag and drop template nodes, connect them, and automatically generate the underlying Python code, thereby lowering the barrier for non‑programmers and educators.

In summary, the proposed DSL offers a high‑level, error‑resistant methodology for specifying large tile sets in the abstract Tile Assembly Model. By encapsulating repetitive glue patterns into reusable templates and limiting the programmer to a small, well‑defined set of operations, the language reduces the cognitive load of tile design, improves code quality, and facilitates the development of visual tooling. Future work includes expanding the operation set, building a full‑featured visual IDE, and exploring compatibility with other self‑assembly formalisms such as the kinetic Tile Assembly Model.