Devlog: Fixing the Typechecker After Bool Enforcement
Getting bool into Flower exposed a reallyyyy annoying problem: the typechecker had a couple of tiny logic mistakes (I’m so good at this) which caused the bootstrap to blow up in my face and I ahd no idea why.
At first the errors looked unrelated. The compiler started reporting huge numbers of mismatches across main.flo, lexer.flo, module.flo, typecheck.flo, and codegen.flo. I was so confused as to why out of nowhere 903 lines were reporting various typechecking errors when they shouldn’t be.
As it turns out, types_match() was the culprit. The function had been inverted in a few places: Mismatched base types and pointer depths were returning success, while normal matching primitive types were falling through to failure. That made the new compiler think ordinary initializers, assignments, comparisons, and returns were all invalid.
Once that was fixed, the remaining failures turned out to be a second real compiler bug: pointer arithmetic over arrays was decaying in the wrong direction. Expressions like:
mods.modules + j
env.structs + env.struct_count
arr + 1
should produce pointer types. Instead, the typechecker was reducing pointer depth when arrays decayed, which made perfectly normal indexed access and table walking look type-invalid.
So this dev session ended up doing three important things:
- fixed
types_match(...)so actual matches succeed and actual mismatches fail - preserved decimal compatibility for
float/doublematching - fixed array-to-pointer decay in pointer arithmetic so compiler internals and examples resolve correctly again
What made this especially annoying is that the symptoms looked much larger than the cause. A couple of bad returns in the typechecker created hundreds of downstream errors, and because Flower is self-hosting, that meant the compiler started rejecting its own source.
After correcting those core issues, both bootstrap and the example test suite started working again. That is the real value of issues like this: not just “fewer errors,” but restoring (MY) trust in the compiler and its ability to enforce Flower’s rules and report issues.
With that stable again, the path forward is much clearer: continue bool work from a solid base, then move on to the remaining numeric and string improvements without the whole compiler collapsing under one bad predicate.
Comments 0
No comments yet. Be the first!
Sign in to join the conversation.