Main SYNX site: https://synx.aperturesyndicate.com/
Version: 3.6.1 — same semantics as synx-core, without maintaining a second grammar implementation in Mojo.
- This folder provides
synx/interop.mojo— thin wrappers around Modular’s Calling Python from Mojo API, importingsynx_native(the PyO3 / maturin extension — same aspip install synx-format). - It is not a from-scratch Mojo tokenizer/parser/engine: duplicating
synx-core+!active+.synxb+!toolin pure Mojo would be a large, separate project (similar in scope to maintaining@aperturesyndicate/synx-formatalongside Rust).
Honest analogy with this repo:
| You said | In-repo reality |
|---|---|
| “like JS” | packages/synx-js is a second implementation (large maintenance). |
| “like Python” | bindings/python is Rust (synx-core) via PyO3, not a pure Python parser. |
This Mojo path matches Python’s pattern: one engine (synx_native), many language frontends.
- Mojo + default CPython visible to Mojo
- Python package
synx-format(providessynx_native):Or from this repo:pip install synx-format
cd bindings/python && maturin develop(uses the same Python env Mojo will load).
Mojo (synx.interop) |
Python (synx_native) |
|---|---|
parse_json |
parse_to_json |
parse_active_json |
parse_active_to_json |
parse_tool_json |
parse_tool_to_json |
stringify_json |
stringify_json |
format_synx |
format |
diff_json |
diff_json |
compile_hex |
compile_hex (.synxb as lowercase hex) |
decompile_hex |
decompile_hex |
is_synxb_hex |
is_synxb_hex (magic probe from hex prefix) |
Note: parse_*_json / diff_json / stringify_json use canonical JSON (sorted object keys) from Rust, aligned with synx-core::to_json.
From bindings/mojo (after pip install synx-format into the Python Mojo uses):
mojo run examples/demo.mojoExpected output: one line of JSON for name / count.
bindings/mojo/
README.md
synx/
interop.mojo
examples/
demo.mojo
Behavior is defined by synx-core 3.6.x and tests/conformance/ — Mojo code only forwards strings to Python.