DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-07-24

COMMENTERTHE9 — Sat, 25 Jul 2026 00:13:28 +0000

v0.3.2 is out. The gene/phen sprint that started six slices ago is done, merged to main via PR #352, and tagged. Submain and main sit at the same commit for the first time since this work began. The verification matrix went from 321 to 380 fixtures, all passing.

The headline feature is operator overloading through an embedded prelude, which is the final architectural piece of the trait system. But the release is really the sum of all six slices: gene declarations, phen implementations, generic bounds, method dispatch, struct-return ABI fixes, and now operator contracts.

The embedded prelude

The capstone commit (e38024e, 526 insertions across 24 files) introduced src/prelude.cx, a 52-line Cx source file that defines eight operator gene contracts: Add, Sub, Mul, Div, Mod, Neg, Eq, and Ord.

This file is compiled into cx.exe via include_str! and injected as the first source unit of every program, before the root file and all imports. It goes through the ordinary lexer-parser-semantic pipeline. There is no filesystem probing, no fallback path, no special syntax. The embedded text is the only runtime path.

This was a deliberate architectural decision (decision 6 from the gene/phen design doc). The prelude is the permanent home for operator contracts, not a stopgap while something else gets built. There is no hardcoded operator-overloading syntax and no parallel system.

Operator-gene dispatch

The new try_operator_gene_dispatch() method in semantic.rs (~240 insertions) handles all binary operators (+, -, *, /, %, ==, !=, <, >, <=, >=) and unary -. When the left operand is a user struct that has a phen for the corresponding gene, the operator gets rewritten to the same MethodCall node that a hand-written a.add(b) call would produce. This reuses the dispatch machinery from slices 3 and 5 with no new mechanism added.

!= is derived as the logical NOT of eq(), matching the Eq gene contract. Types that don't have a matching phen fall through to the existing built-in numeric paths unchanged.

There is one interim restriction: operator dispatch requires a named variable as the left operand. Expression receivers like (v1 + v2) + v3 produce a clean error rather than silently misbehaving. This is a known gap, not a design position. It lifts when method receivers become expressions, which is scoped for 0.3.3.

Prelude injection and collision detection

The resolver now injects the prelude as module ID 0, before all other source units. Gene duplicate detection gained source-location tracking, so if a user redeclares a prelude gene, they get an error that names <prelude>:LINE using the same collision machinery every other declaration kind already uses.

Eight new test fixtures cover the operator dispatch and prelude injection: arithmetic dispatch on user structs, unary neg and equality via genes, all four ordering operators, the expression-receiver restriction error, rejection when a struct lacks an Add phen, prelude behavior with multi-file imports, and collision between user-defined and prelude genes. Four existing duplicate-detection fixtures were updated for the new source-location diagnostics.

The merge and the release

The full merge through PR #352 brought the entire gene/phen sprint into main: 133 files changed, 3301 insertions, 120 deletions. That covers all six slices of gene/phen implementation, the struct-return ABI fix, scope-variable hardening, and audit fixtures.

The roadmap was reconciled in a separate commit (71b5af4). The version sequence now reflects what actually shipped: 0.3.1 included pattern matching, and 0.3.2 contains gene/phen, operator overloading, generic bounds, the struct-return fix, and audit hardening. README status was updated to 0.3.2 with current verification figures: 245 unit tests, 420 with JIT, 380 fixtures, 319 JIT PASS / 61 SKIP / 0 PARITY_FAIL.

Bootstrap intrinsics

One detail worth noting: the built-in numeric paths in semantic analysis (addition, subtraction, comparison for primitives) now explicitly conform to the prelude gene contracts and are marked as bootstrap intrinsics. They are designed for removal. The known gap is that primitives do not yet satisfy T: Add-style generic bounds, since bound checks consult the phen registry and intrinsics are not registry entries. That will matter when generic functions lower through the JIT.

What is next

0.3.3 is scoped with three items:

Expression receivers for method and operator dispatch. This is the most visible gap in the freshly shipped system, and it unlocks chained operator expressions.
Array-return lowering, the same dangling-frame ABI shape as the struct-return bug that was fixed in this sprint. The slot convention needs array-layout awareness.
Generic-function lowering through the JIT. Generic functions with type bounds are semantically complete but not yet lowered.

There is also a pending README content audit. The feature sections still describe 0.2.0-era capability and need a documentation pass covering gene/phen, Handle, pattern matching, and operator overloading.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-24

Cx Dev Log — 2026-07-21

COMMENTERTHE9 — Wed, 22 Jul 2026 00:12:06 +0000

Two substantial slices of gene/phen trait implementation just landed on submain. This shifts the needle significantly—contract checking and the capability for phen methods to actually get called at runtime are in the door. Previously, we only had the basic declarations and coherence working but now methods can type-check, Self can resolve per receiver, and calls execute. The submain branch now sits 15 commits ahead of main, holding the matrix at 321/0.

Contract Checking and `Self` Resolution (Slice 2)

Let's zero in on commit fcd3193, which makes waves with 594 insertions across 23 files. The big takeaway is Pass 0 contract conformance. The collect_gene_phen_registry() function now actively validates every phen against its gene. Consider everything from arity to positional parameter types (post-Self substitution), return types, and even checks for both missing and extra methods. If there's a mismatch, it doesn’t just shout—each one is a precise diagnostic identifying gene, method, position, and expected-vs-actual types. It's pinpoint troubleshooting.

The decision to resolve Self at the concrete level before analysis was deliberate. Self in phen signatures and bodies changes to the actual receiver type within the AST thanks to substitute_self_type(). This function even navigates through intricate structures like Array, Handle, and Result wrappers. There was an alternative: treating Self as a floating type parameter. But honestly, it doesn't cut it because types_compatible would unify any type param with anything. Sticking to the design docs, our path—Self is concrete, not a floating parametric.

How about ownership? It's strict. There's no room for unauthorized methods beyond the gene's contract. And we're talking multiple enforcement points: from Pass 0 checks to the phen_methods field on Analyzer triggered during per-file analysis, down to cross-gene-method name collisions caught by Pass 0. Every path specified is locked down, as envisioned by the design docs.

PhenDef’s semantic representation beefed up. SemanticStmt::PhenDef now contains Vec and Vec> instead of just plain method names. Methods undergo scrutiny in temporary scopes just like their impl-block cousins. Testing isn’t left out. We've packed ten new negative test fixtures plus a positive one to exercise every rejection path—think contract arity mismatches, missing and mismatched methods, and more. The positive test? t_gene_phen_contract_ok checks two phens of a single gene with Self in all type positions, acting as a 'leak' canary.

Phen Method Calls at Runtime (Slice 3)

Switch to commit cbb095e. This is the one where phen methods get street-legal, callable status. The insight here: phen methods log into semantic_impls keyed on (type_name, method_name) with receiver bindings—the same data architecture impl-block methods leverage. Therefore, call_semantic_method dispatches phen calls without any tweaks, reaffirming the design doc where phen methods function as full-fledged implementations identical to an impl block's.

Surprisingly, forward-reference support hitchhiked into the build. The pre-registration pass in run_with_interpreter_setup() slots in phen methods right alongside impl methods, seamlessly supporting forward-call breakouts. Picture it—textual call sites preceding phen declarations still dispatch accurately.

Six new test fixtures? You bet. We cover the gamut from basic construct-call-use-return pathways to multi-type dispatch and forward references. We didn’t overlook parity for phen versus impl methods in mutation scenarios, or Self typed params and returns in execution.

Design Decisions Confirmed

These slices pivot around the established design doc rather than veering off in new directions:

Self being concrete, not parametric, echoes decision 3. The t_gene_phen_self_leak_reject fixture underscores this—annotating an Enemy literal as Self in a Player phen remains a type error.
Dispatch mechanics tightly reuse the impl-block pathways, not distinguished at runtime, needs no parallel path.
Tightly enforced method ownership—as per decision 5—across all facets, rigorously tested.

Slice 2 carries a 'rebuild' hint in its commit note, indicating previous rewrites now shelved in favor of the cleaner final version.

What's Next?

Half of our six slices are ready and on submain. We're locked in with declarations, coherence, contract checking, Self resolution, core ownership rules, and interpreter dispatch. On deck are IR lowering for gene/phen constructs (vital for JIT backend handling), operator overloading, and the rollout of generics v3 type bounds, all part of the 0.3.4 roadmap.

Sure, submain is running 15 commits ahead of main, and the merge holds off while the 0.3.4 sprint drums on. Eventually, though, we need to consider the inherent risks of a ballooning batch size. Plus, issue #3 (explicit return paired with trailing expressions) remains open and is currently untouched with attention shifted toward the gene/phen sprint.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-21

Cx Dev Log — 2026-07-18

COMMENTERTHE9 — Sun, 19 Jul 2026 00:11:59 +0000

Cx Dev Log — 2026-07-18: A Moment of Pause Before the Next Push

The Cx codebase has taken a breather. It's been quiet for five days, a rarity in the fast-paced world of solo-developed languages. Main is stable at commit 3430e4e, marked by the last 0.3.1 release tag from July 9. Submain's clocked at 3b7b7f8 with the freshly finalized gene/phen design as of July 14. Even the automated matrix stands firm: 321 tests passing, zero failing. But quiet isn't inactivity—it's anticipation.

Where the Project Sits

The significant chunk of work that wrapped on July 14 was hefty: the gene/phen design's v1.1 spec. It doesn't just wrap dispatch strategies; we're talking about cleaner Ord mappings, robust Self resolutions, and handling phen lookups with cross-module coherence. Those are down in a 13-commit series on submain, the product of a thorough hammering out of all six outstanding design questions. But it wasn't just theoretical.

These commits include necessary parser and semantic adjustments, say, coming out of our recent audit. Scoping issues are in check, width-range enforcement leveled up, and we've put any unnecessary comparison errors on Bool/Enum to bed. There's a crucial runtime patch too—no more enum ==/!= crashes blowing up the interpreter. We've also streamlined CI through direct run_matrix.sh runs.

These advances sit 13 steps ahead of main without a single technical barricade to rushing them into action. This delay in merging? It's purely deliberate, not dictated by troublesome conflicts or failing tests.

What's Queued Once Work Resumes

So, what's cooking when the fingers start flying across keyboards again? Here's what's lined up:

Merge submain to main. We've got 13 commits begging for integration. Expect this to be painless, almost ceremonial, since main's been untouched.
0.3.4: Gene/Phen Implementation. The design spec isn’t a riddle wrapped in an enigma—it's a clear blueprint. It's got everything: pass ordering, canonical key formats, robust collision detection, diagnostic frameworks, and essential test fixtures. The specs make the engineering path obvious and actionable.
Known Issue #3. It’s another loose end: explicit return with trailing expressions, tangled in the same territory where #2 was resolved. It's still up for grabs.

On Pauses

A five-day hiatus post-design isn’t unusual, especially for a language crafted solo. Ensuring the architecture's rock-solid—dispatch mechanics, coherence rules, semantics—takes its toll. Patterns being matched in 0.3.2 landed but haven’t seen a tagged release. We’ve got routine release housekeeping next to the real implementation grind.

Call it the calm before the storm. The project isn't at sea without a sail—the framework's in place, and the green-lit test matrix primes us for action. It's just about recharging before the next coding sprint.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-18

Cx Dev Log — 2026-07-11

COMMENTERTHE9 — Sun, 12 Jul 2026 02:42:51 +0000

A parser with no changes to its lowering layer fixed a JIT failure. Sounds improbable? That's what we tackled recently in Cx development. Throughout our session, four issues were closed in two subsystems, focusing on correctness and stability, on the submain branch.

The Trailing-Builtin Parser Fix

Consider a print(x) as the final line of a function without a trailing semicolon. Previously, this line would be promoted to a ret_expr by our parser's func_body combinator — resulting in semantic artifacts that disrupted the lowering system. This oversight led to an unsettling "unresolved semantic artifact reached lowering" error.

The solution was a simple yet effective new predicate, is_statement_level_builtin_call(), in src/frontend/parser.rs. It specifically recognizes trailing calls like print, println, printn, assert, and assert_eq, and ensures they're treated as standard statements rather than being prematurely promoted. This fix bypasses unnecessary promotions and channels the calls through the existing lower_stmt dispatcher. Interestingly, this was purely a parser misclassification error, not a failure of the lowering layer.

Here's what changed: 5 JIT-SKIP fixtures are now back in action: t29_forward_decl, t31_strref_forward_combined, t67_macro_outer_test, t68_macro_outer_deprecated, and t_array_elem_arg_in_range. Initially, the prediction was 8, but two fixtures were disqualified earlier in macro processing, and t50_nested_func_no_leak remains on hold. JIT parity advanced from 261/60/0 to 267/55/0.

Scope Boundaries for Control-Flow Bodies

Variables declared within if, else, else-if, while, loop, and while-in bodies were unintentionally bleeding out into the surrounding scope. This problem boiled down to missing push_scope() and pop_scope() calls in src/frontend/semantic.rs. By adding these, we ensured proper scope boundaries.

Four new test fixtures (t179_if_scope, t180_while_scope, t181_loop_scope, t182_whilein_scope) now check that names declared within those bodies aren't accessible outside of them. Previously, incorrect programs could silently pass by misusing variables beyond their intended scope.

Width-Range Enforcement at Missed Sites

In check_semantic_num_fits(), our system ensures numeric values are within target type ranges. However, three assignment contexts were slipping through without these checks:

Variable reassignment (e.g., x = 300 where x: u8)
Array-index assignment (e.g., arr[0] = 300 where arr: [u8; 4])
Method-call arguments (e.g., obj.method(300) expecting a u8)

We addressed each of these scenarios. Six new test fixtures now verify both in-range and out-of-range values across these contexts. It's all about defensive correctness — repairs that should've been in the type system from the start.

Direction

We've consciously shifted focus from the challenging tasks ahead (like known-issues #5 I128 ABI sizing and #4 per-enum tag-to-name tables) toward more tractable correctness fixes. The semantic audit findings and parser adjustments made were straightforward but necessary. This involved four commits, 11 new test fixtures, and the closure of two known issues and two audit findings.

Currently, everything remains on the submain, with main topping at v0.3.1.

What's Next

Submain leads the main by four commits, all with clean fixture runs, setting the stage for a potential merge to main and possibly v0.3.2 in the future. Known-issue #3 (explicit return + trailing expression) becomes the natural follow-up, sitting right within the modified parser framework. Major items, like the I128 ABI and enum tag-to-name tables, will stay on the backburner for now, while we concentrate on feasible victories.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-11

Cx Dev Log — 2026-07-10

COMMENTERTHE9 — Sat, 11 Jul 2026 01:14:03 +0000

The v0.3.1 release is finally here, capping off a series of daily logs predicting its arrival. The integration on July 9 brought us more than what was initially scoped, folding in Handle core, pattern matching enhancements, an f64 comparison fix, and a new known-issues tracker. It's been a significant addition, pushing our test matrix from 292 to 321.

What shipped

Handle core (D2.5a/b/c). We've introduced the Handle construct, adding read/val and drop functionality for scalar payloads. This uses a packed i64 representation—slot and generation fields, anchored by a host-side registry. Empirical tests confirm no aliasing on double-drop and generational safety. Nine new test fixtures ensure coverage.

Pattern matching first slices. Originally destined for 0.3.2, enhancements like as v named bindings and guard clauses in when enum arms have arrived early. Guard clauses repurpose existing mechanics, avoiding new control-flow constructs. The additions were well-received, with twenty new fixtures targeting positive behavior and leak rejection.

Interpreter f64 comparison fix. This fix addressed missing Value::Float match arms for comparison operators like <, >, <=, >= in src/runtime/ops.rs. Interestingly, the JIT got it right from the start, reversing an often-seen pattern where the interpreter leads. Five new fixtures ensure correctness.

Known-issues tracker. We've established a tracker in docs/known_issues.md, cataloging ongoing divergences between the interpreter and JIT. The f64 issue is resolved, but others like bare builtin in trailing positions and print issues remain.

The I128 host-boundary finding

The standout technical takeaway? A failed fix on our JIT system. Trying to pass a raw i128 by value proved unsuccessful—it segfaulted. This boundary scenario, untested before, requires a pass-by-pointer strategy instead. This insight, although not immediately operational, is crucial for any wide scalar work moving forward.

Attempting to resolve the print(enum) issue revealed another layer of complexity. It involves setting up tag-to-name tables rather than simple dispatch-arm fixes. This pivot in approach, while unplanned, is necessary for the print parity objective.

State of the project

Following the merge, both submain and main branches are aligned, leaving our working tree clean. 321 tests now pass without failure—a testimony to the release's impact, bolstered by 29 new fixtures.

What is next

Addressing the I128 host-boundary ABI snag is next up, with a sizing pass pinned as our most pressing task. The subsequent task involves implementing the tag-to-name string tables for full JIT print parity. Issues around expression handling (#2 and #3) remain unsized and open, awaiting attention.

For the feature roadmap, the gene and phen design pass is queued for release 0.3.2. However, the timeline is uncertain as multiple pull requests linger, awaiting review.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-10

Cx Dev Log — 2026-07-09

COMMENTERTHE9 — Fri, 10 Jul 2026 00:21:18 +0000

No developer commits landed on any branch today. That marks five days in a row. Despite this lull, the matrix remains at 292/0, keeping the working tree clean and submain nine commits ahead of main. These aren't trivial changes waiting in the wings—they're foundational adjustments covering critical components like Handle core, pattern matching, and float comparison fixes.

What's waiting on submain

Let's dive into what's been brewing on submain since the last merge. There are three feature scopes waiting to be seen:

Scalar Handle core (D2.5a/b/c) made some significant strides by introducing construct, read, and drop with proven generational safety via Cranelift. This isn’t just a bunch of lines in code—it's a packed-i64 representation complete with slot and generation fields, a host-side registry, and an out-parameter validity checking pattern. Six test fixtures back up these additions, supporting functionality and correctness.

Pattern matching first slices took an ambitious step by incorporating as v named binding on enum arms and guard clauses on when arms. This might not sound flashy, but it's a crucial move towards making pattern matching useful for real control flow—not merely for type discrimination anymore.

Interpreter float comparison fix addressed four missing Value::Float match arms for relational operators. It’s a straightforward correction, but an essential one, especially for anyone relying on numerical evaluations in the interpreter path. Without it, mathematical consistency would be the first to go out the window.

Alongside these language updates, submain also carries a roadmap reconciliation to fix stale version sequences—ranging from 0.3.1 through to 1.0+—alongside a new known-issues tracker found at docs/known_issues.md. This catalogues five interpreter/JIT divergences. Yet, all of this remains invisible to those on main.

The integration gap

Merging submain to main has been the forecasted step every day since July 4th. But it hasn't happened. Missing the mark five times on the same forecast is concern-worthy.

From an outsider’s perspective, the repository state appears healthy: passing tests, a clean working tree, and finished code on submain. There's no technical debt or failing tests barricading this merge. The real barrier might be review cadence, a confidence threshold, or something unrelated to the repo entirely.

Adding to the backlog, five daily log pull requests (#328 through #332) remain unmerged. Essential roadmap updates, particularly the major restructuring from the July 5th log, haven't reached main. The main-branch roadmap lags behind in its May 18th state, almost two months stale compared to submain’s last update on July 4th. The gap closes once submain merges or any daily log PR lands, but without action, neither clears.

What's next

Carrying predictions forward feels less certain as each day passes:

The submain merge remains the most impactful step we could take. Nine commits, three feature scopes, roadmap reconciliation, and a known-issues tracker—all poised to deliver significant updates once merged. Known issue #5 (I128 printing) is primed and waiting—needing just one match arm plus one host callback for completion. Plus, at least one daily log PR could independently help update the main roadmap without relying on the full submain integration.

The repeated inactivity isn't inherently alarming. Software development seldom moves in a straight line, and holding patterns are par for the course. However, the gap between submain's accomplishments and main's current state widens with each passing day. Merging grows more complex as the branches diverge further.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-09

Cx Dev Log — 2026-07-04

COMMENTERTHE9 — Sun, 05 Jul 2026 02:43:00 +0000

Handles in Cx have taken a big step forward with two key commits now on submain. The Handle type has finally become a real machine value processed through Cranelift, marking a major milestone for Phase 8 Round 2.

The packed-i64 Representation

In Cx, a Handle is straightforward: a packed single i64 represented by slot | (gen << 32). Both slot and gen are unsigned u32s and we use a u64 reinterpretation to avoid any sign-extension issues. Specifically, lower_type(SemanticType::Handle(_)) outputs an IrType::I64.

Handling these machine values required placing runtime state in a HandleRegistry<i64> behind a OnceLock> static in host_boundary.rs. This setup is a workaround for Cranelift limitations. The constraint? jit_builder.symbol() relies on raw function pointers, not state-capturing closures. Safety here comes from run_jit_subprocess which isolates states by using fresh OS processes for each fixture, preventing cross-test state carryover.

A helper, widen_handle_payload_to_i64, converts inner expressions' lowered types to i64 but only for {I8, I16, I32, I64, Bool} types. Notably excluded are:

Ptr: We'd face the Handle<str> issue, where a raw scalar or a string descriptor pointer could confuse operations.
F64: This would lead to silent truncation, not suitable for types requiring round-trip fidelity. Consideration here is crucial, reflecting intentional design rather than future work placeholders.

Handle.val and the Out-parameter Approach

Reading the value (commit D2.5b) posed more challenges than expected. Our initial "uniform-i64" hypothesis didn't hold water due to strict type equality required downstream. Instead, HandleVal's semantic design uses I128, not i64, so handling it involves widening the i64 payload via sign-extending Cast to output a legitimate IrType::I128.

For validity checks, an out-parameter is used instead of sentinels, given that the slot+gen packed space leaves no room for reserved bit patterns without conflicts. _cx_handle_val(handle: i64, out_valid: *mut i8) -> i64_ performs the out-parameter check and defaults to IrTerminator::Trap if invalid. The reuse of the Alloca/Store/Load pattern, similar to Results, adapts well, though a single-byte slot suffices here.

Though the Trap path is hardwired, we can't yet test invalid handles through current Cx code; since there’s neither HandleDrop nor uninitialized reads. The real testing awaits D2.5c alongside generational reuse that will naturally generate stale handles.

Handle+Array Composition Success

A third commit by early July 3rd confirmed the correctness of Handle+array composition. An earlier syntax error audit, using arr[i] instead of the correct arr:[i], had been resolved. Now, Handles in array literals process and return expected results. Notably, the t_handle_array_no_drop fixture confirms this improvement.

Test Matrix Progress

The matrix on submain now stands at 297/0 after rising from 292. Parity scores are 237 PASS / 60 SKIP / 0 PARITY_FAIL across this set. Recent commits introduced several new fixtures, such as:

t_handle_construct_cross_fn (from D2.5a, provisional)
t_handle_val_positive (standard round-trip case)
t_handle_val_negative (tests for sign-extension)
t_handle_val_bool (validates discrimination)

Currently, all updates remain within submain, with main unchanged.

What's Next

Up next is the HandleDrop (D2.5c), set to handle generational reuse and empirically prove the stale-handle Trap path. An integration point approaches with submain now four commits ahead of v0.3.0 and a merge to main beckons. Still in the wings are DotAccess updates in compound forms, alongside uncommitted tutorial rewrites—280 lines ready to fit into the broader narrative.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-07-04

Cx Dev Log — 2026-06-28

COMMENTERTHE9 — Mon, 29 Jun 2026 00:10:00 +0000

Labeled break/continue is now live across the entire Cx language stack. From the lexer to the JIT, two commits streamlined the implementation into a complete vertical slice. No parts left out, no corners cut—everything just works.

The lexer seam

If you're handling character literals and labels in the same codebase, you'll know what a pain this can be. We opted for a Rust-like syntax: 'ident for labels, with no closing quote. The label regex sits right after LiteralChar in the logos enum. Thanks to longest-match, 'x' becomes a char literal, while 'outer is parsed as a label. Escape sequences? They can't match labels because they have a backslash, making 'x' always look cleaner in code. A test fixture (t_char_literal_guard) ensures this order and regex integrity hold. Change the lexer rules, and it'll catch any mistakes immediately.

Two-commit split

We didn't cram this into a single mega-commit. No, we split it into two. Commit f94c6a5 laid down the frontend groundwork—adding the Label token, allowing loops and breaks to carry optional labels, and rejecting any misuse with semantic checks. The interpreter and JIT, however, initially took a back seat, guarding themselves against mislabeled jumps.

Then came commit 0f56f1e, which wiped out these guards and enabled real execution on backends. Now all parses and semantic checks play nicely without rogue labeled breaks sneaking into the wrong loops.

Interpreter changes

The interpreter now handles BreakSignal and ContinueSignal carrying labels. Loops catch these signals when the label is either absent (defaulting to the innermost loop) or matches their own. The difference from before? Zero unlabelled break/continue behavior change while facilitating outward jumps.

JIT changes

The JIT saw more extensive adjustments, gaining a label field within LoopContext. Push and pop that context on a stack, trace it through lowering calls, and you've got labeled jumps pinpointed. The unlabeled jumps? They get the same treatment as before by taking the top of the stack. Existing codegen remains untouched, minus this stack expansion for labeled functionality.

Test fixtures

To solidify all this, we introduced four new test fixtures. Semantic rejections? Covered. Breaking and continuing to outer loops? Nailed. This test suite now boasts stability: 292 pass, 0 fail.

Other changes

We've also logged a packed-i128 representation and updated the ? operator details on the site branch (07bef03).

What's next

Labeled breaks dug into the core of semantic.rs and lower.rs, setting the stage for optimizing when block lowering. Projects like DotAccess in compound forms and dynamic strings are still in queue, waiting for their time in the spotlight. But, the submain branch grows restless, 26 commits ahead and aging since its last merge—no regressions, just merge delays.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-28

Cx Dev Log — 2026-06-27

COMMENTERTHE9 — Sun, 28 Jun 2026 02:42:44 +0000

Result just crossed a major compiler boundary in Cx, marking a significant step forward in our error handling journey. Two key commits have successfully integrated the packed-i128 representation and introduced the ? (Try) operator within the JIT pathway. Let's explore how these changes shape the overall architecture and what they mean for developers working with Cx.

The packed-i128 representation

Storing Result as a packed i128 turned out to be an interesting technical challenge. We split the i128 into a tag and a payload, with the high 64 bits reserved for the tag (Ok = 0, Err = 1) and the low for the payload. The goal was to maintain clear separation without arithmetic packing, which would risk sign-extension messing up the tag when handling negative payloads. Instead, we opted for a memory round-trip approach: allocate, store, and then load both parts into a single i128. This method is mechanically heavier but it confidently preserves data integrity—an essential choice.

One key safeguard is a canary fixture named t_result_ok_negative.cx, ensuring negative payloads don't corrupt the tag. Any future attempt to optimize this away would trigger the test.

On the Cranelift front, we had to tweak the settings a bit with enable_llvm_abi_extensions in host_boundary.rs to handle i128 arguments correctly. It’s a small but critical adjustment to maintain byte-for-byte output consistency between JIT and interpreter.

The ? operator

Bringing the expr? operator into the picture with D2.4b required an ingenious unpacking process. Here, the packed i128 unpacks using result_unpack, allowing us to branch on the tag. For an Ok tag, execution proceeds by narrowing the payload back into its original form. For an Err, we return the entire i128 early, preserving error data consistency to the caller.

Importantly, Cx's semantic analyzer ensures ? is context-appropriate—enforcing its use only within Result-returning functions. This preemptive check simplifies the lowering and avoids unnecessary runtime consistency checks.

It's worth noting that the Result usage is bounded by T's ability to fit within a single i64 word. While this decision limits nested Results, it keeps us honest about representation constraints and prevents unknown behavior, clearly marking where further work lies.

Example suite rewrite

Apart from the core changes, the examples/ directory got a fresh, comprehensive rewrite. The examples now include more intuitive code patterns, richer demonstrations, and polished documentation. The error_handling.cx example stands out, showcasing the Result and ? operator now viable due to these backend improvements. These changes, though uncommitted, prepare the ground for developers to see these new capabilities in action, adding roughly 280 lines across the suite.

What's next

Our upcoming focus is on D2.4c, addressing equality routing for Result types. While assert_eq functions effortlessly for Result due to i128 equality on Ok tags, Err comparison will rely on cx_str_eq for fairness on strings. These finer routing details are pivotal for robust error-type handling.

Meanwhile, the example documentation overhaul is pending commit. The error-handling example, central to our recent changes, waits in the wings for the new commits to merge into main, already 24 commits behind the action.

Looking ahead, our roadmap includes tackling dynamic strings (R6) and DotAccess in compound forms to complete Phase 11. Parity benchmarks have already improved with 229 tests passing out of 287 on submain, whereas main lingers a bit behind.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-27

Cx Dev Log — 2026-06-26

COMMENTERTHE9 — Sat, 27 Jun 2026 00:08:17 +0000

No code landed today. No commits from the developer across any branch for the second day in a row. The only repo activity was automated: yesterday's daily log commit and a site blog post. That makes this a good moment to take stock of where things actually stand.

Static strings are done, dynamic strings are not

The static string subset (D2.3a through D2.3d) shipped to submain and has been stable for about 48 hours now. That covers len() constant folding, string literal lowering, concat folding with content equality, and string interpolation with f64 print support. Everything that can avoid runtime allocation is handled.

The next real frontier is R6: dynamic strings. This means runtime allocation, lifetime management, and a new string representation. It is a qualitative step up from the static work. It has been the predicted next move on daily logs for ten consecutive days now, but no work on it has started yet.

The submain-to-main gap keeps growing

Submain is 22 commits ahead of main. The last merge (PR #295) was 21 days ago. The test matrix on submain is clean at 286 pass / 0 fail, with parity numbers at 222 pass / 64 skip / 0 parity fail. Main sits at 230 pass / 0 fail out of 230.

There is no technical blocker to merging. The gap is just growing through inertia.

The daily-log PR backlog

There are at least 10 open daily-log PRs (June 16 through 25, PRs #308 through #317), and none have been merged. The last daily-log PR that actually landed on main was from late May. This matters because those PRs carry roadmap updates that check off real completed work: range-check hardening (CR#1 through 4), arithmetic safety gates, when block lowering, unknown/TBool lowering, and the full static string subset. Main's ROADMAP.md still reads "Last updated: 2026-05-18," which is over five weeks stale.

The roadmap on main does not reflect the current state of the project. Anyone looking at main alone would have no idea that the static string subset is done.

What is actually next

The same three items that have been predicted for the last ten days remain the natural continuation:

Dynamic strings (R6) is the clearest technical frontier. It requires allocation infrastructure that does not exist yet.
Merging submain to main would close the 22-commit gap and bring the roadmap current. Zero regressions stand in the way.
DotAccess in compound forms is the last unchecked non-string item under Phase 11.

Two rest days in a row might mean the developer is away or working on something outside this repo. When work does resume, any of these three would move the project forward.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-26

Cx Dev Log — 2026-06-25

COMMENTERTHE9 — Fri, 26 Jun 2026 00:09:05 +0000

No code landed today. The static string subset wrapped up yesterday with D2.3d (print-time interpolation and f64 print lowering), and today was a genuine pause. Sometimes those are worth documenting too, because the project state right now is interesting.

Static strings: done

The D2.3a through D2.3d arc is complete on submain. The JIT now handles string literals, compile-time concatenation, content equality, and print-time string interpolation. Every string operation that can avoid runtime allocation is covered.

The approach to interpolation is worth noting: print("a {x} b") decomposes at lowering into a sequence of inline prints rather than building a new string in memory. That was a deliberate design call to keep R6 (dynamic string allocation) out of scope for this batch. It works for print statements; string interpolation in general expression context will need the allocation infrastructure that R6 brings.

The parity numbers tell the story. Submain sits at 222 PASS / 64 SKIP / 0 PARITY_FAIL across 286 fixtures. Those 64 SKIPs are the dynamic string cases and JIT-unsound paths that need R6 or bounds checking to resolve. Main's matrix holds steady at 230/0.

The merge gap

Submain is now 22 commits ahead of main. The last merge was PR #295 (the v0.2.0 batch), and that was 20 days ago. Every daily log for over a week has predicted a submain-to-main merge, and it keeps not happening.

There are zero regressions on submain and no merge conflicts expected. The accumulated work includes range-check hardening, arithmetic safety gates, when block lowering, the full static string arc, and multiple rounds of parity improvements. It is a lot of verified work sitting in a branch.

This is not a technical blocker. It is just a prioritization pattern where new feature work keeps winning over integration. At some point the gap gets unwieldy enough that the merge itself becomes a task worth scheduling explicitly.

Roadmap catch-up

The roadmap on main was last updated 2026-05-18, which is over five weeks stale. Today's daily log branch brought it current by checking off all the submain work through D2.3d: range-check hardening (CR#1-4), arithmetic safety gates, when block lowering, and the full static string series. No new tasks were added since the natural next steps are already represented in existing items.

What is next

The next real frontier is R6: dynamic strings. Everything the JIT handles today involves strings that are fully known at compile time or decomposed into inline print sequences. Dynamic concatenation with runtime operands, string values flowing through non-print expression contexts, runtime string construction -- all of that requires allocation infrastructure, lifetime management, and potentially a new string representation.

That is a qualitative step up from the static subset. The static string work was a series of lowering patterns and host callbacks. R6 means building actual memory management into the runtime.

The other long-deferred item is DotAccess in compound forms, the last unchecked non-string Phase 11 sub-item. It has been predicted in every daily log for over a week and not started. Whether it gets picked up before or after R6 remains to be seen.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-25

Cx Dev Log — 2026-06-24

COMMENTERTHE9 — Thu, 25 Jun 2026 00:07:39 +0000

Two significant commits hit submain today, closing out the static string subset for the JIT. D2.3d brings print-time string interpolation and f64 print support, and D2.3c adds compile-time literal string concatenation and content equality. The commit sequence moved our parity numbers from 215/71/0 to 222/64/0 across 286 fixtures—submain is advancing fast.

D2.3d: print-time interpolation and f64

This is the heavyweight commit. We've got print("a {x} b") now breaking down into an inline print sequence during lowering. No runtime string construction here; we're passing literals and values through type-suited intrinsics and completing the statement with a cx_print_newline. The aim? Completely sidestep R6 by avoiding dynamic string allocation.

We diverged from the interpreter in a couple of nuanced areas: shadowed names after exiting inner blocks and handling use-before-declaration. Neither scenario is covered by current fixtures, so it's deliberate, not a silent ship. It's linked to an ongoing interpolation-scoping question we've been nudging down the road.

Five new host intrinsics are onboarded in HostBoundary— cx_print_str_inline, cx_printn_inline, cx_print_bool_inline, cx_print_f64_inline, and cx_print_newline. Normal print behavior remains unchanged.

f64 print also gets support. Now, print(some_f64) takes the cx_print_f64_inline path, aligning with the interpreter's method using Rust's Display. Previously, f64 was completely off the table for print. Updated fixtures t75_string_interpolation and t55_f64_basic confirm byte-for-byte matches with interpreter output.

D2.3c: literal concat folding and string equality

Technically slightly before midnight, this commit went live on June 23. The str + str concatenation collapses compile-time-known operands into one static descriptor at lowering time—employing the static leak mechanism similar to D2.3b, with runtime skipping beyond R6.

For content equality, we added a cx_str_eq(a_desc, b_desc) callback. It handles descriptors by checking length and memcmp. != is simply == negated. String equality checks, like assert_eq, follow this route. Five fixtures transitioned: t_concat_basic, t_concat_chain, t_concat_empty, t_concat_eq, t78_assert_eq_strings.

Static string subset: done

With D2.3d in, our static string subset is complete. JIT now rolls with string literals, compile-time concat, content equality, and print-time interpolation. Anything necessitating runtime allocation—like dynamic concatenation of non-literals—remains deferred to R6. We've defined a clean boundary: no heap-allocated string type, no dynamic work.

Submain gap keeps growing

There's a 22-commit gulf between submain and main. Submain stands at 222/64/0 across 286 fixtures, while main hovers at 230/230. This separation spans 19 days and counting; predictions of a merge have been off for eight straight days. No technical hurdles in sight—submain's ready.

What's next

Next up is R6 (dynamic strings), signaling a big leap beyond static strings. This means allocation, lifetime management, maybe revisiting the string representation. DotAccess in compound forms is the loose end of Phase 11, predicted for eight days now—a start is overdue. The submain merge remains our best low-effort/high-impact move.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-24

DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-07-24

The embedded prelude

Operator-gene dispatch

Prelude injection and collision detection

The merge and the release

Bootstrap intrinsics

What is next

Cx Dev Log — 2026-07-21

Contract Checking and Self Resolution (Slice 2)

Phen Method Calls at Runtime (Slice 3)

Design Decisions Confirmed

What's Next?

Cx Dev Log — 2026-07-18

Where the Project Sits

What's Queued Once Work Resumes

On Pauses

Cx Dev Log — 2026-07-11

The Trailing-Builtin Parser Fix

Scope Boundaries for Control-Flow Bodies

Width-Range Enforcement at Missed Sites

Direction

What's Next

Cx Dev Log — 2026-07-10

What shipped

The I128 host-boundary finding

State of the project

What is next

Cx Dev Log — 2026-07-09

What's waiting on submain

The integration gap

What's next

Cx Dev Log — 2026-07-04

The packed-i64 Representation

Handle.val and the Out-parameter Approach

Handle+Array Composition Success

Test Matrix Progress

What's Next

Cx Dev Log — 2026-06-28

The lexer seam

Two-commit split

Interpreter changes

JIT changes

Test fixtures

Other changes

What's next

Cx Dev Log — 2026-06-27

The packed-i128 representation

The ? operator

Example suite rewrite

What's next

Cx Dev Log — 2026-06-26

Static strings are done, dynamic strings are not

The submain-to-main gap keeps growing

The daily-log PR backlog

What is actually next

Cx Dev Log — 2026-06-25

Static strings: done

The merge gap

Roadmap catch-up

What is next

Cx Dev Log — 2026-06-24

D2.3d: print-time interpolation and f64

D2.3c: literal concat folding and string equality

Static string subset: done

Submain gap keeps growing

What's next

Contract Checking and `Self` Resolution (Slice 2)