Devlog: Making Flower’s Type Aliases Transparent

This version was simple to develop on paper (and even in practice it wasn’t too bad, only around 4 or so hours!):

type Count = int
type Total = Count
type Name = string

and then have those aliases behave like the real type everywhere:

n: Count = 12
total: Total = identity(n)
name: Name = "Ivy"

if name != "Ivy":
    return false
end

if name.length != 3:
    return false
end

That meant aliases could not just be parsed and stored, but rather had to be transparent to the compiler’s semantic checks.

What changed

I added type alias declarations to the AST, parser, and type environment, then added the ability to resolve aliases in typechecking before comparing types.

That included:

• return type checks
• variable initializers
• function call arguments
• binary comparisons
• string-specific comparison logic
• struct field access

The important rule here is that aliases are semantic, not codegen-facing. Count should behave as int, Name should behave as string, and chained aliases like Total -> Count -> int should collapse correctly. In the future, especially post v2.0, this could change and custom types might become real — but for now, they’re just aliases.

The bug that exploded bootstrap

The first real failure was not in aliases themselves, but in function argument checking.

Inside check_call_args(...), the compiler was resolving the argument expression into expected_type instead of arg_type. That overwrote the parameter type, left the actual argument type uninitialized, and caused the second bootstrap stage to explode into over a thousand misleading errors. This was not a pre-existing issue, it was instead from human error (my error) during the initial implementation where I accidentally put the wrong variable.

Once that was fixed, the remaining failures were much more helpful than the bright flash of red and “Typecheck failed with 1224 error(s)” message!

Where this leaves v1.4

With the first step toward “better types” done, aliases are no longer just syntax. That gives v1.4 a solid base for whatever comes next in the type system without having to fake around raw names.

During this whole dev session, I did discover that a whole lot more of the source code was left using legacy work-arounds: int instead of bool, name_start; name_length and @char instead of string. In all fairness, some of these aren’t exactly the easiest to refactor. However, I will probably hold off on refactoring the codebase until either right before v2.0, or right after. Just know it’s on my radar ;)