Devlog: Making Flower’s Bool Support Real Enough to Survive Bootstrap

The goal sounded small at first: add proper boolean support, while still lowering booleans to integers in C.

In practice, this turned into an overarching type-system problem (typical!).

Flower had reached a point where bool could not just be a naming trick over 1 and 0. The compiler itself needed to understand when an expression was semantically boolean, when it was integer, and when older bootstrap-era shortcuts were no longer valid.

A lot of those shortcuts had survived because the backend lowers bool to int anyway. But self-hosting exposed a major issue: source-level typing and C lowering are not the same thing.

Things like these started breaking:

val: int = parser_peek(ps).kind == TOKEN_TRUE

and helper predicates that returned comparison expressions from int-typed functions.

So the checkpoint became: keep C lowering simple, but make Flower’s typechecker treat booleans as a real source-level type.

The main changes were:

parser -> typecheck -> codegen

• true / false now parse into AST_BOOL_LIT
• bool literals are still emitted as 0 / 1 in C
• logical and comparison expressions now resolve to bool
• arithmetic rejects bool operands
• if, while, and not now validate condition-compatible expressions
• variable initializers, assignments, and returns now check types more strictly

One of the more annoying bugs turned out not to be “about bools” at all.

When code like this failed inside the compiler:

defined_structs[i].length
emitted_imports[i].path

the real problem was that for i in 0..count was never registering i in the type environment, so indexed access looked broken when really the loop variable itself had no known type. Once loop indices were typed as int, those field-access failures disappeared (yay!!).

The result is a much better place to build from:

• bool is now semantically distinct in Flower
• it still lowers cleanly to integer values in generated C
• bootstrap works again
• the compiler is stricter without collapsing under its own source

That makes the next step much easier: real string support, instead of trying to build strings on top of a type system that still half-thinks everything is an int.