CX · Reference guidecx-binding-v
PlaygroundDownloadsAboutv0.18.0-pre.1

cx-binding-v

the native reference binding

Why reach for it

The native reference binding: the engine's own language, with no ABI in between. cx-binding-v is the V binding of CX, and it is two things at once: the native path imports the reader and the evaluator's V modules directly from its pin of the front door, and the archived C-FFI path shows the same surface reached the way every other binding reaches it — through libcx.

Layer 1 is the contract every binding shares: sixteen canonical methods — parse, bytes, hash, equals, eval, select, modify and the node accessors — with identical semantics across hosts, and this binding is the reference the others are measured against: what it answers natively is what cx_canonical, cx_hash, cx_eq and cx_code_eval answer through the ABI, or one of them is wrong. layer-1 is the table, c-abi the surface the others wrap.

We grade the binding against the front door's published ABI vectors — one case per entry point, an input document and the canonical output, hash or refusal it must answer — through the binding's own test, written in V, which loads the file from its pin and asserts every vector through its own calls. The same file is checked against libcx directly by the front door's C test, so the native path, the ABI and the engine are held to one witness.

What it gives you

No CX module: a binding ships host code, not .cx files, so the table below is the generator's note. What it gives you is the V module itself — the Layer-1 methods over the engine's own types — and the archived FFI implementation beside it, kept as the worked example of wrapping the ABI.

This repository ships no bundled module of its own; what it gives you is above, and its links are below.

Try it

One ABI vector, replayed by this site's cx: a document with a presentation comment, kept through cx_fmt — the lossless canonical text the binding's fmt answers. The binding's own test asserts the same vector natively; this page shows the engine's own answer.

input.cx

        # a note about the user
[user id=1 name="Alice"]
      
        $ cx --from=cx --to=cx input.cx
# a note about the user
[user id=1 name=Alice]
      

Fixture abi-001-fmt-lossless-retains-comment in deps/cx-core-code/conformance/abi.cxd — replayed against this cx when the page was built.

Status

The binding is not consumed by cx — it consumes cx: its own deps.cxd pins the front door for the V core the native path imports and the libcx the archived path links, which is why the registry row carries no at= and the figure draws no column on either side. It ships from its own repository at its own cadence, and a pin moves there only when the newer front door passes with it.

fact as the registry records it
ships as v-module
status extracted
pinned at ea14483a9 — the registry's at=; deps.cxd carries no row for it, so nothing of it is in the build
builds on none recorded — the registry row carries no pins= column yet
built on by nothing pins it yet
bundled modules 0
BUILDS ON THIS REPOSITORY · SHIPS BUILT ON BY none recorded — no pins= on the registry row yet cx-binding-v no bundled module — see its row nothing pins it yet DRAWN FROM registry/repos.cxd's pins= COLUMN AND registry/modules.cxd WHEN THIS PAGE WAS BUILT
Fig. — what cx-binding-v plugs into: the repositories it builds on (left), the modules it ships (centre), the repositories that build on it (right) · drawn from registry/repos.cxd, deps.cxd and registry/modules.cxd when this page was built