This paper presents a detailed examination ofmetacircular virtualization in the Nock combinatorcalculus, focusing on the practical implementationof a virtualized Nock interpreter within theUrbit ecosystem. We explore the design andfunctionality of key components, including the++minkinterpreter,
and their roles in enablingrobust Nock execution environments. Extensions ofNock using fake opcodes, particularly opcode 12,are discussed, and a minimal working example of aNock-virtualized Nock formula is provided.
The Nock combinator calculus is used as a target instruction
set architecture (isa) for the Hoon and Jock languages.
However, Nock itself is a “crash-only” paradigm which has no
error handling mechanism within the terms of the isa itself.
Furthermore, sometimes information is necessary to complete
a calculation which may not be present in the apparent
subject. Practical Nock interpreters handle this by running
Nock within Nock, a process of metacircular virtualization.
This article explores the design of ++mock, the
basic
virtualized Nock interpreter, and its role within a Nock-based
kernel and standard library.
2 Background
In 1958, John McCarthy began his lifelong work on the
Lisp programming language (McCarthy, 1996). While
the form would evolve over the years, the fundamental
components included S-expressions, or parenthesized
lists of homoiconic code–data; ’ or quote, a deferred
expression; and eval, a function to evaluate quoted
code.1
Together these components allowed McCarthy and colleague
Steve Russell to implement a Lisp interpreter in Lisp itself, the
first metacircular interpreter (McCarthy and Wexelblat,
1978). Such was a radical departure from the imperative
programming paradigm of the time, exemplified in Fortran
(1954–55); Lisp’s reliance on recursion and higher-order
functions was both a precursor to the functional program
paradigm and a rejuvenation of the Church and Curry schools
of fundamental computing logic.
Metacircularity was considered sufficiently important that
several programming languages implemented it as a first-class
feature, including Forth, TeX, and Prolog. They have
generally been used either for tightly interpreted features like
debuggers and code introspection tools, or for language
extensions like macros.
Amin and Rompf (2017) analyzed how metacircular
interpreters build on top of each other, each adding a new
layer of abstraction. While primarily considering a Lisp
dialect, they showed how interpreted language extensions
(even in cascading towers) can be collapsed to bottom-level
interpretation, similar to Nock’s own ++mink
function. They
epitomized a line of research on reflective languages and
self-interpreted languages, such as quasiquotation in Lisp
(Bawden, 1999) and Template Meta-Haskell (Sheard and
Jones, 2002). The ultimate point of this enquiry was to show
that metacircularity was a powerful and well-grounded tool for
building interpreters, and that it could be used to in fact build
practical interpreters.
Before Nock was even christened, one of its earliest design
criteria was to straightforwardly implement a metacircular
interpreter (~sorreg-namtyv, 2006; ~sorreg-namtyv, 2010). While
the original motivation was to implement a hyper-Turing
operator over a referentially transparent bound namespace,
Nock’s support for virtualization also soon proved useful for
managing error traces and crashes. Yarvin wrote in an early
document:
Metacircularity in most languages is a
curiosity and corner case. Programmers are
routinely warned not to use it, and for
good reason. Practical metacircularity is a
particular strength of Nock, or any functional
assembly language. Dynamic loading and/or
virtualization works, at least logically, as in an
OS.
We hypothesize that a metacircular functional
dissemination protocol can serve as a complete,
general-purpose system
software environment—there is no problem it
cannot solve, in theory or in practice. Such
a protocol can be described as an “operating
function” or OF—the functional analog of an
imperative operating system. (~sorreg-namtyv,
2010)
Metacircularity thus closely ties to the idea of a functional
operating system. This is a theme that has been explored in
other contexts, such as the Lisp machines and the Haskell ghc
runtime system. For Nock, a virtualized interpreter is
no mere corner case but a first-class component of the
system, both for practical execution and for resource
discovery.
3 Virtualized Nock
Given an argument for metacircularity, we can now examine
how Nock is actually virtualized in practice. The Urbit
standard library provides a metacircular Nock interpreter,
++mink, along with several other components for
building
virtualized Nock environments. Some essential components
provided by vanilla Hoon for virtualizing Nock include:
++mink, compute
bottom-level virtual Nock.
++mock, compute formula
on subject with hint.
Wraps ++mink; common entrypoint.
++mule, kick a trap
(deferred computation). Wraps
++mock; common entrypoint.
++soft, wrap a typecast
as a unit (i.e., fail with ~
rather than crash).
Nock execution environments virtualize Nock for two
primary reasons:
Crash handling (provisional execution).
Language extension (additional opcodes).
3.1 Crash handling
While virtualization necessarily incurs some overhead relative
to more direct execution, it gives the Nock programmer a way
to bail (crash), trace (log with debugging information), and
bind (time-limit) a computation. In fact, stack traces are
computed through virtualization, and so are guaranteed to be
as correct as their implementation.
A Nock virtualization environment needs to distinguish at
least three kinds of results:
A successful result of computation, along with a valid
Nock noun.
A block, which indicates that the computation is not
yet complete and should be continued.
A halt or deterministic error, which indicates that
the computation has failed and should not be
continued.
These correspond to standard scry results (see “Opcode 12”
below) in this order:
[~~noun],
a successful result.
~, a result is not
currently available (block).
[~~],
a result will never become available (halt).
Because Nock is untyped and we need to distinguish a “zero”
from a “block”, the structure of each scry result fundamentally
differs from the other options.
Nondeterministic errors—crashes in the runtime, such as an
out-of-memory error—are not handled by or visible to the Nock
interpreter as a solid-state computer.
3.2 Language extension
Virtualization enables the extension of Nock using “fake
opcodes”. At the current time, only opcode 12 has been
added;2
this opcode provides a generalized way to supply the OS
context to the scope in a way that appears like a GOTO or
remote call but actually preserves Nock semantics including
strict subject scoping. There is a sense in which the scry
operation and the bound (referentially transparent) scry
namespace are identical to the metacircularity of the Nock
interpreter itself. The operating function itself can be treated
as a first-class member of its own ecosystem.
Hoon defines +$nock already
suited for virtualized Nock
execution including fake opcode 12 (Listing 1).
However, while ++mink is
compiled to and evaluated
in Nock, it is written in Hoon and accordingly uses
Hoon’s affordances, particularly vases. Vases are a
pair of type and data intended to store relevant type
information for correctly evaluating raw untyped Nock
nouns.3
Accordingly, it is Hoon’s higher-level introspective tools that
facilitate ++mink’s operation.
The remainder of this section analyzes how each ++mink
implements each Nock opcode, including particularly the fake
opcode 12. The following code samples are taken from
/sys/hoon in the Urbit codebase.
++mink produces a head atom
marking the kind of result
the interpreter has raised: if a %0, the result
is a valid Nock
noun; if a %1, a block is indicated (i.e. the
halting problem
continues); if a %2, then a deterministic error
has occurred
with an error trace.
3.3 Opcode 0
Opcode 0 is the identity function, which returns its argument
unchanged. This is implemented in ++mink as
follows:
In essence, an axis is provisionally extracted from the
subject; if this is ~ then an error is raised with the current
execution trace, else the resulting value from that axis is
produced.
3.4 Opcode 1
Opcode 1 is the constant function, which returns a constant
value extricated from the formula. This is implemented in
++mink as follows:
::*[a1b]b[%1constant=*][%0constant.formula]
3.5 Opcode 2
Opcode 2 is the evaluation function, which evaluates the
formula on the subject. This is implemented in ++mink as
follows:
Like opcodes 3 and 4, this reduces to an evaluation of
a base-level opcode 5 after checking the left-hand and
right-hand formulas.
3.9 Opcode 6
Opcode 6 is the if-then-else or conditional branch function,
which evaluates the formula on the subject and then evaluates
either the first or second formula depending on the result.
This is implemented in ++mink as follows:
As with the direct opcode 6, there is no short-circuit
evaluation in the conditional statement.
3.10 Opcode 7
Opcode 7 is the composition function, which evaluates
the formula on the subject and then evaluates the next
formula on the result. This is implemented in ++mink as
follows:
Here the conceptual differences between opcode 7 and opcode
8 can be sharply compared: how 7 requires an evaluation
against the current subject, leading to something of the nature
of \(c(b(a))\) in terms of function composition, versus how 8 simply
augments the subject.
3.12 Opcode 9
Opcode 9 is the arm select function, which selects an arm of
the subject and evaluates it. This is implemented in ++mink
as follows:
For all the mechanics involved in opcode 9, the implementation
is perhaps surprisingly simple. Extract the arm at the axis and
evaluate it structurally using an opcode 2. (As an aside, Hoon
which compiles to Nock aggressively utilizes lambdas to define
functions at the point of use, and frequently employs a
gate-building gate pattern. This latter resolves to two opcodes
9 in series.)
3.13 Opcode 10
Opcode 10 is the edit function, which edits a value in the
subject at the given axis. This is implemented in ++mink as
follows:
++edit traverses the noun to
attempt to access a given axis;
if it succeeds, it returns a new noun with the original value at
that axis replaced by a new target value. If it fails, it returns
an empty unit, indicating without a crash that the edit
failed.
There’s more plumbing here because of the mutation of the
noun, but the essential concept of locating and replacing a
valid subtree is straightforward.
3.14 Opcode 11
Opcode 11 is the hint function, which provides a hint to the
interpreter about how to interpret the argument. This is the
only way to produce side effects from Nock as a pure function,
and ++mink respects and passes through hints
raised by the
virtualized Nock formula. This is implemented in ++mink as
follows:
Two options match for opcode 11, a static and a dynamic hint.
Even though this virtualized code “sandboxes” execution, the
Nock formula including the clue is in fact evaluated. The
runtime listens for a clue, which is compared to a whitelisted
set of supported hints, as in normal (nonvirtualized) Nock
execution.
Note that the argument cannot simply be discarded
by the interpreter, because it may result in a crash.
Thus, as with direct Nock execution, the hint must be
evaluated.4
3.15 Opcode 12
Opcode 12 is the scry function, which
retrieves a value from the sky namespace
environment.5
This is implemented in ++mink as follows:
Opcode 12 does not have a direct Nock expression since it
“steps outside” the subject–formula pair via the expedient of
the scry gate.
In order to interpret opcode 12, ++mink takes
as an argument, in addition to the subject
and formula, a gate which will be invoked
with the results of the subformulas of 12 as a
sample. The result of executing this gate (not
as interpreted by ++mink but by whichever
interpreter is running ++mink) are then
treated as the result of the Nock 12 operation.
(“4n ++mink”, Urbit documentation)
Much of consequence is entailed by the use of a scry gate,
which is a Hoon function that retrieves a value from an
associated sky namespace (nominally, the bound
scry
namespace, although this is not necessarily entailed by Urbit
in contemporary practice). The scry function
bears the
signature
$-(^(unit(unit)))
The result of this operation is either a noun or a block, and it
is returned as a (unit(unitnoun)).
These correspond to
standard scry results in this order:
[~~noun],
a successful result.
~, a result is not
currently available (block).
[~~],
a result will never become available (halt).
For instance, the reference roof function for Arvo, the
Urbit kernel, is schematically defined as:
An excursus is here warranted. The Arvo core is the
Nock-based kernel of Urbit, and it is responsible for managing
the state of the system and providing a consistent interface for
agents to interact with that state. The Arvo core is built on
top of the Nock interpreter, and it uses the ++mink function
to interpret Nock formulas. Each vane in the Arvo core
receives a +$roof in its function call, which it
can call when
it needs to scry with opcode 12. This gate provides access to
the vane’s state, and it is used to retrieve values from the
vane’s state in a way that is consistent with the Nock
semantics.
++look is a gate that is used to
convert the
++mink-compatible version of the scry handler
into a version
that can be used by the Arvo core. This gate acts as a bridge
between the .^ dotket and the scry handler
(++look) with
access to the roof that came from the vane. This pattern
imposes constraints on interpreters, but provides a way to
mediate access to the state of the system in a way that is
consistent with Nock semantics. Thus .^ dotket
gives
mediated access into the sky without exposing
the state of
the entire system in the subject (untyped permissions-free
access).
3.16 Et cetera
++mink also features some
machinery to correctly implement
the cell distribution rule.
++mink is naturally jetted for
efficiency, ultimately by
u3m_soft_run()
in Urbit’s Vere (C) and by interpret()
in NockApp’s NockVM (formerly Sword) (Rust), both the
virtualization context for their respective runtimes. Some
internal affordances for the runtime are in place to keep
execution consistent; e.g., scry gates are stored on a stack to
prevent re-entry if it scries.
Nock is a crash-only language, which means that
when something goes wrong, the exception is an
exception for the runtime or virtual machine to handle
as it will. Typically, for a runtime this means an
injection of the error trace back into the Nock kernel
(cf. section “u3n: nock execution” in u3.md in the Urbit
documentation6 ).
(For ++mink, errors are attempted to be
front-run by the
interpreter and thus bad Nock should not be executed as
such.)
4 Nock in Nock
Hearkening back to Amin and Rompf’s collapsed towers of
interpreters, the affordances of ++mock as a
metacircular
interpreter permit us to build a tower of interpreters on top of
it without incurring excessive performance overhead. As the
author of u3.md concluded for the Vere C runtime, “we simply
treat Nock proper as a special case of mock.”
The conventional
++mink gate is built in Hoon, but what if we
stripped it down
and built it in Nock itself with the minimal necessary
machinery? What would such an interpreter look like, and
how would it relate to actual operation on a runtime in
practice?
Let us extend ++mink to
implement a logical loobean
operator. (Call the modified gate ++pink.) This
operation
will be invoked with a new fake opcode 13. Under the hood,
opcode 13 will simply logically negate a value (via an opcode
6).
Finally, it is instructive to consider what the minimal
required amount of code machinery would be for one to
successfully implement a Nock metacircular interpreter in
Nock itself. An examination of ++mink shows
modest
reliance on Hoon’s higher-level features; tree math, for
instance, in ++cap for distinguishing head vs.
tail and
++mas for finding the relative address of an
axis. (Neither
of these are particularly complicated, but they entail
some basic arithmetic operations as well.) By omitting
++scry and opcode 12, as well as reducing to a
structural
match with a +$tone instead of an explicit Hoon
type
match, one could produce a reasonably sized Hoon program
compiling to something close to the minimal viable Nock
virtualized interpreter. No doubt intrepid code golfers
will find it very much an upper bound rather than a
lower.
This Nock formula produces a working virtualized Nock
interpreter derived from Hoon code with some hand tuning.
The input function signature is [subject=*formula=*]
with output of the form [@product=*];
if the head is %0,
then the product is a valid Nock noun, while a head of %bail
indicates a crash in the evaluation. Opcode 9 calls may be
addressed into the core as subject, and the formula itself is
complete with an empty subject.
Metacircular virtualization is a powerful tool for building
interpreters, and Nock is not only no exception, it exemplifies
the practice. The design of ++mock and its
underlying
++mink function provides a practical way to
interpret Nock in
a way that is both efficient and extensible. One could imagine,
for instance, a Nock interpreter cousin to ++mock that
is instrumented for partial evaluation of formulas (as
in a debugger or syntax highlighter robust to syntax
errors). Nock supports a rich capacity to build metacircular
interpreters as a first-class feature, a potential which
remains as yet relatively unexplored in the Nock ecosystem.
References
Amin, Nada
and
Tiark Rompf
(2017).
“Collapsing
towers
of
interpreters.”
In:
ProceedingsoftheacmonProgrammingLanguages.
Vol. 2.
popl.
New
York,
NY:
Association
for
Computing
Machinery,
pp. 1–33.
url:
https://doi.org/10.1145/3158140
(visited
on
~2025.8.13).
Bawden, Alan
(1999).
“Quasiquotation
in
Lisp.”
In:
Proceedingsofthe1999acmsigplanworkshoponPartialevaluationandsemantics-basedprogrammanipulation.
New
York,
NY:
Association
for
Computing
Machinery,
pp. 4–12.
url:
https://dl.acm.org/doi/10.1145/317636.317640
(visited
on
~2025.8.13).
McCarthy, John
and
Richard L. Wexelblat
(1978).
“History
of
lisp.”
In:
Historyofprogramminglanguages.
Ed. by
Richard L. Wexelblat.
New
York,
NY:
Association
for
Computing
Machinery,
pp. 173–185.
url:
https://doi.org/10.1145/800025.1198360
(visited
on
~2025.8.13).
Sheard, Tim
and
Simon Peyton Jones
(2002).
“Template
meta-programming
for
Haskell.”
In:
Proceedingsofthe2002acmsigplanworkshoponHaskell.
New
York,
NY:
Association
for
Computing
Machinery,
pp. 1–16.
url:
https://dl.acm.org/doi/10.1145/581690.581691
(visited
on
~2025.8.13).
1Paul Graham, in his 2001 short essay
“What Made LispDifferent”, grouped these concepts into the phrase “The whole languagealways available” (2001).⤴
2Compare, however, the approach of
~barpub-tarber, pp. 191–228in this volume, who presented an explicitly constructive Nock-likeparadigm in Ax.⤴
3See ~lagrev-nocfep, pp. 131–153 in
this volume, for a discussionof vases and their role in practical Nock compilation.⤴
4Here, this should be read “evaluated
safely”, with the caveatthat some hints may result in a runtime crash. For instance, anill-formed %sloghint (printf) will
crash the interpreter if theclue is not structured correctly. This is a consequence of the factthat Nock is untyped and so the interpreter cannot know whetherthe hint is well-formed or not. The ++minkinterpreter does
notattempt to validate hints, but merely passes them through to theruntime for evaluation. (One could imagine a Nock virtualizer whichitself handled certain hints as if they were “side effects” to theevaluation.)⤴
5There is a sense in which opcodes
6–11 are also virtualizedextensions to Nock, acting as they do as macros. See ~niblyx-malnus,pp. 47–70 in this
volume.⤴
6This section devoted a fair amount of
attention to opcode 11 now12 (it being written for Nock 5K) and hint evaluation.⤴
