[housejester]

On a dialect with booleanType: 'none', the expression compiler now tracks whether each edge of the compiled expression tree wants a value or a condition, and asks the dialect to coerce where they differ: a condition where a value is wanted becomes CASE WHEN c THEN 1 WHEN NOT (c) THEN 0 END, a value where a condition is wanted becomes v = 1. On a dialect with boolean values both hooks are the identity, so nothing changes there.

In the boolean_coercion experiment the translator stops refusing a boolean in a value position, so a model written for DuckDB runs unchanged on SQL Server; the result reader already shows the 1/0 as true/false. Without the experiment the refusals from malloydata#3147 stay as they are. The pass runs either way, which is what closes the two holes in malloydata#3171 that the translator could never see: all() of a boolean measure and a boolean primary key are expressions the compiler builds itself.

What a boolean compiles to, with the experiment on:

Malloy	SQL on SQL Server
group_by: big	CASE WHEN ai>5 THEN 1 WHEN NOT (ai>5) THEN 0 END as "big"
where: big	WHERE (ai>5)
having: all(anyn)	HAVING (MAX(CASE WHEN … END) OVER () = 1)
primary_key: big, then pk.count()	COUNT(DISTINCT (CASE WHEN … END))
a second stage's where: big	WHERE (base."big" = 1)
where: pick big when ai > 1 else false	WHERE (CASE WHEN (ai>1) THEN (CASE … END) ELSE … END = 1)
where: big ~ f'not true'	WHERE (CASE WHEN (ai>5) THEN 1 ELSE 0 END = 0)
sql_number("""CASE WHEN ${big} THEN 1 ELSE 0 END""")	left as written

Two things stay refused because there is no value to make: a cast to boolean, and (unchanged from today) arithmetic or a time operation on a boolean. having: all(x) compiles but SQL Server rejects a windowed function in HAVING for any x; that needs its own compilation and is out of scope.

Testing: boolean-coercion.spec.ts in lang/test checks the generated SQL for each shape on the test dialect, and test/src/databases/sqlserver/boolean-coercion.spec.ts runs them on a live SQL Server. Every shape from the fuzz corpus behind malloydata#3171, plus every refusal case from malloydata#3147, was also executed against SQL Server 2022; everything boolean-specific runs and returns the DuckDB result, and what remains failing is either a generic type error the translator already gives or a SQL Server limitation unrelated to booleans.