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
| Quality | Calor Approach | Result |
|---|---|---|
| Comprehension | Explicit structure and contracts | 1.84x in the v0.12 calculator |
| Error Detection | First-class preconditions/postconditions | 1.49x in the v0.12 calculator |
| Edit Precision | Optional stable IDs for structural targets | 1.36x in the v0.12 calculator |
| Parseability | Indentation + prefix notation | Regular, compiler-defined grammar |
| Verifiability | Contracts in syntax, not comments | Machine-checkable specs |
What Calor Trades Away
| Quality | Impact | Mitigation |
|---|---|---|
| Raw Token Count | Calor pays a premium on small programs | Evaluate the full token/character/line composite |
| Information Density | 0.98x vs C# | Near parity; C# narrowly leads |
| Human Readability | Unfamiliar syntax | Not the target audience |
| Ecosystem | .NET interop may require manifests or preserved C# | Import, effect manifests, and interop blocks |
| Tooling | No bundled editor extension | Use the CLI, or point any LSP-capable editor at calor lsp |
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))
// ...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
- The declared balance relationships are visible for review
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)))An agent can immediately verify:
- Any call with
discount_percent > 100violates 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}The ID gives the edit a stable target and reduces the risk of changing the wrong loop.
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:
| Code | Calor Tokens | C# Tokens |
|---|---|---|
| Hello World | ~25 | ~15 |
| FizzBuzz | ~80 | ~50 |
| Simple CRUD | ~200 | ~130 |
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 x3. 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:
| Metric | Measures | Calor Result |
|---|---|---|
| Token Economics | Token/character/line composite | 1.42x (Calor wins; raw tokens still cost more) |
| Information Density | Semantic content per token | 0.98x (C# wins) |
| Comprehension | Benefit of explicitness | 1.84x (Calor wins) |
| Error Detection | Contract signals | 1.49x (Calor wins) |
| Edit Precision | ID-based targeting | 1.36x (Calor wins) |
| Correctness | Structural estimation signals | 1.29x (Calor wins) |
| Generation Accuracy | Compilation and structural completeness | 1.02x (Calor wins) |
| Refactoring Stability | ID-reference preservation | 1.38x (Calor wins) |
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