Devlog: Fixing Flower’s Output Driver and Starting the String Stdlib

This checkpoint was really two different kinds of progress that ended up helping each other a lot.

The first part was not glamorous, but it was necessary: Flower’s compile driver was tripping over its own default output naming. This was a known issue that I had been putting off, but for some reason it really annoyed me this time so I decided enough and to fix it.

If no explicit output path was provided, the compiler would generate output.c, then strip the .c and try to emit a binary named output. That worked fine right up until the repo itself already had an output/ directory. At that point, linking failed because the compiler was trying to create a file where a directory already existed.

Worse — because it annoyed me more — the driver logic was also mixing up “the generated program exited non-zero” with “compilation failed.” That became especially annoying during bootstrap, because the generated compiler binary would run without CLI arguments, print its own usage error, and then cause bootstrap to report failure even though codegen and C compilation had both succeeded.

So I finally got off my butt and cleaned that up.

Driver Cleanup

The default output path now goes to:

output/out.c

which naturally produces:

output/out

as the binary.

That avoids the old output filename collision.

I also separated compile success from auto-run behavior:

explicit output path: compile only
default output path: compile, then auto-run if appropriate

That means bootstrap no longer “fails” just because the compiled compiler exits non-zero with missing arguments, and demo/test files can still run automatically when that is actually useful.

This sounds like a small driver fix, but honestly it removed a lot of noise from string work — and more — immediately.

String Stdlib Beginnings

Once that output weirdness was under control, I could finish doing what I just started and actually wanted: making string behavior live in Flower instead of endlessly leaning on ad hoc C calls (Call back to last devlog, absolute ball knowledge!!).

So I added the first real reusable helpers in src/stdlib/string.flo:

is_empty(s)
starts_with(s, prefix)
ends_with(s, suffix)
find_char(s, ch)

These are intentionally simple. They mostly exist to prove that the current string support is now strong enough for normal library code to be written on top of it. Not incredibly useful, at least at the level the compiler needs, but at least I could translate some AP Comp Sci A into Flower hehe

A string feature does not really feel “real” until I can build helpers with the language itself instead of only teaching the compiler more special cases. The day I remove the builtin C handlers is the day I’m at peace…

Validation

To exercise that new library surface, I changed string_pass.flo to now act as a small pass file for the experimental library.

Its job is not to be impressive. Its job is to answer a more important question:

can I import string helpers, call them from normal Flower code, and get expected results through the full compile pipeline?

At this point, yes.

Where this leaves things

This checkpoint did not remove all C string dependencies from the compiler. In fact, it removed essentially none! That is still a separate step, one that may even be in v1.3.7 ;)

But it did establish two important things:

Flower’s output/driver behavior is now much less annoying.
We can start growing a real string library in Flower itself.

That is a good place to be, because the next string work can build outward from a stable driver and an actual library surface instead of piling more special behavior into the compiler.