Tradeoffs

Calor deliberately trades certain qualities for others. Understanding these tradeoffs helps you decide when Calor is the right tool.

The Core Tradeoff

Calor trades token efficiency for semantic explicitness.

// C#: 4 tokens, implicit semantics
return a + b;

// Calor: Explicit Lisp-style operations
§R (+ a b)

This is a fundamental design choice, not a flaw to be fixed.

What Calor Optimizes For

What Calor Trades Away

When the Tradeoff Pays Off

Calor's tradeoff pays off when:

1. Agents Need to Reason About Behavior

§F{f001:TransferFunds:pub}
  §I{Account:from}
  §I{Account:to}
  §I{i32:amount}
  §O{bool}
  §E{db:rw}
  §Q (> amount 0)
  §Q (>= from.balance amount)
  §S (== from.balance (- old_from_balance amount))
  §S (== to.balance (+ old_to_balance amount))
  // ...
§/F{f001}

An agent can reason about this function's behavior without reading the implementation:

• It modifies database state
• Amount must be positive
• Source must have sufficient balance
• Balance transfer is atomic (from decreases, to increases by same amount)

2. Agents Need to Detect Contract Violations

§F{f001:CalculateDiscount:pub}
  §I{f64:price}
  §I{f64:discount_percent}
  §O{f64}
  §Q (>= price 0)
  §Q (>= discount_percent 0)
  §Q (<= discount_percent 100)
  §S (>= result 0)
  §S (<= result price)
  §R (* price (- 1 (/ discount_percent 100)))
§/F{f001}

An agent can immediately verify:

• Any call with discount_percent > 100 violates preconditions
• If result is negative, postcondition is violated
• The contracts document edge cases explicitly

3. Agents Need to Make Precise Edits

// Instruction: "Change the loop in f001 to iterate from 0 instead of 1"

// Before
§L{for1:i:1:100:1}

// After - target is unambiguous
§L{for1:i:0:100:1}

No ambiguity about which loop to modify. No risk of changing the wrong one.

When Traditional Languages Win

Use C#/Python/etc when:

1. Token Budget is Critical

If you're operating at the edge of context window limits, C#'s compactness wins:

2. Human Developers Are Primary Readers

Calor's syntax is optimized for machine parsing:

// Familiar to humans
if (x > 0) return x;

// Less familiar
§IF{if1} (> x 0) → §R x §/I{if1}

3. You Need Library Ecosystem

Calor compiles to C#, so interop is possible, but native library support doesn't exist.

4. You Need Full Formal Methods

If you need to prove arbitrary mathematical properties—cryptographic protocols, compiler correctness, or complex algorithms—use a proof assistant like LEAN, Isabelle, or Rocq. Calor provides lightweight verification for software contracts, not a theorem prover. It targets development teams defining business logic requirements that AI agents implement, not mathematicians writing proofs.

Measuring the Tradeoff

Our evaluation framework measures both sides:

The question isn't "which is better" but "which matters more for your use case."

Next

• Benchmarking Overview - How we measure these tradeoffs
• Results - Detailed evaluation data