Types & Conversions

This page explains which kinds of values can be compared, combined or joined, and which combinations are treated as author mistakes.

The type-discipline rules

• Equality is cross-type-tolerant at runtime, strict at save time. equal(5, "5") is false (and notEqual is true) rather than an error — a condition is often exactly where an author probes messy upstream data, and failing the run there would be harsher than answering "no". Where the declared input schema proves the two operands' types can never match, static analysis reports it at save time instead. One equality semantic serves the whole engine, including INCLUDES and in/notIn.
• Ordering requires comparable types. lessThan("abc", 5) is a coded error, never a silent answer — unlike equality, ordering has no defensible answer across incomparable types: neither true nor false is right, and JS's own answer (false for both < and >) is a known trap that makes lessThan and greaterThanInclusive simultaneously false. Strings order against strings, numbers against numbers, dates against dates, by exact value — never locale collation.
• Conditions are booleans only, with one carve-out for null. A bare string or number where a condition is expected is a coded error — there is no "0 is false but "0" is true" rule to mis-learn. null counts as false, so a missing optional flag does not fail a run on its own.
• + is numeric only; CONCAT is the only string join. "a" + "b" is a type error — JS's overloaded + is the single largest source of "1" + 1 = "11" defects, and one token with one meaning is what both the type lattice and the diagnostics want. Use CONCAT to join text.