Devlog: Making Bool Real Without Breaking Bootstrap
The original goal, asper usual, was straightforward: before moving on to string, Flower needed bool to actually mean something semantically.
Up to this point, boolean-ish behavior mostly worked by accident. Comparisons, conditions, returns, and general expression checking were still loose enough that the compiler could get away with treating a lot of things as “close enough,” especially since the C backend ultimately lowers bool to int anyway.
That was not going to hold once v1.3 started leaning on richer typing.
So this was about drawing a clean line between Flower semantics and C lowering.
The Goal
In Flower:
-
boolshould be its own real type - comparisons and logical operators should produce
bool - arithmetic should not quietly accept
bool - implicit conversion should stay narrow and predictable
- explicit casting should remain available through
as
In C:
-
boolcan still lower toint
That distinction ended up being the easy part.
What Changed
- The typechecker now treats
boolas a proper language type instead of an int-shaped placeholder. - Condition checks were tightened so
if,while, andnotuse condition-compatible rules. - Arithmetic paths now reject boolean operands, and return / initializer / argument checking now runs through more explicit conversion rules.
I also kept implicit widening one-directional:
int -> float -> double
while leaving narrowing conversions as explicit casts.
The actual implementation of booleans and their typing, enforcement, and semantics was a breeze. It’s what came after that got me.
What Actually Broke
As usual, bootstrap had opinions.
The stricter type work exposed older weaknesses that were easy to miss before (This is my coping):
- function argument checks needed array-to-pointer decay
- alias and module call lookup paths were too narrow
- unresolved calls could prevent nested expressions from being fully type-resolved
- that, in turn, broke some dot-access lowering and caused bad
.vs->emission in generated C
So part of this checkpoint turned into compiler stabilization work rather than just bool semantics due to my crappy ‘temporary’ logic, error handling — or lack thereof, and impeccable ability to miss very important details.
I’m an amazing programmer, if you couldn’t tell :p
Result
Flower now has a much firmer semantic base for bool, and the compiler is back to bootstrapping cleanly with those rules in place.
That matters because this was really the floor for the next part of v1.3: string.
And.. maybe I’ll fix the bootstrap process so it doesn’t blow up in my face again. Oh yea, forgot to mention that. The bootstrapper bootstrapped itself into this very broken parser state that refused to go away so I had to stash my changes, checkout the prior merge (detached), and then recompile manually and fix the parser.
Toodles!
Comments 0
No comments yet. Be the first!
Sign in to join the conversation.