The Snowcat Bug That Misread String As BOUNDS

When Apalache’s Snowcat misinterprets string literals like "OUT_OF_BOUNDS" as BOUNDS (an integer interval), it’s not just a quirky error - it reveals a deeper tension in how type systems handle human-readable strings. In v0.55.0, the type checker flags that "OUT_OF_BOUNDS" cannot fit where a string literal is expected inside a Set literal, even though other elements parse fine. This isn’t a typo - it’s a blind spot in literal coercion, especially when string content mirrors internal type names. Think of it: a set with one element ‘OUT_OF_BOUNDS’ gets rejected as BOUNDS, the numeric type. The bug survives because annotations can’t override this inference, forcing developers to rename constants - often impractical in large codebases. This matters because it undermines clarity: a set meant to hold strings gets misread as a numeric range, confusing both machines and humans. The fix isn’t trivial - no workaround yet - because renaming breaks the literal’s purpose. But ask yourself: when a string meant to be literal becomes a type error, who’s really miscommunicating?

Here is the deal: A set literal should reflect its elements’ true types, not internal metadata. The error surfaces consistently, even in simple sets, revealing a disconnect between literals and inferred types.

This bug taps into a broader pattern: modern type-safe languages often struggle with human-centric literals. Snowcat’s checkers assume strings are text, not types - yet in practice, “OUT_OF_BOUNDS” reads like a boundary. The real risk? Misinterpretation creeps into documentation, tests, and legacy code. Stay vigilant - this isn’t just a bug, it’s a warning about type system design.

Here’s the core: String literals in set contexts are not always what they seem. When “OUT_OF_BOUNDS” triggers a BOUNDS error, it’s a signal that type inference prioritizes structure over semantics.

Here is the catch: The error persists despite type annotations because the type checker treats the string as a contextual BOUNDS reference, not a literal. No fix exists yet that preserves intent without renaming.

Here is the takeaway: In Apalache 0.55.0, consider literal clarity over type shortcuts. When types clash with strings, transparency beats coercion. Are you sure your set literals reflect the real data you intend?

The Bottom Line: A string literal shouldn’t be a type trap. When types misread meaning, it’s time to rethink how literals and semantics coexist in your code. How often do you assume a string is a value when it’s actually a type hint?