You are browsing as a guest. Sign up (or log in) to start making projects!

Open comments for this post

3h 48m 29s logged

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:

  • bool should 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:

  • bool can still lower to int

That distinction ended up being the easy part.

What Changed

  • The typechecker now treats bool as a proper language type instead of an int-shaped placeholder.
  • Condition checks were tightened so if, while, and not use 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!

0
9

Comments 0

No comments yet. Be the first!