Tradeoffs
Reader question: When is Calor worth evaluating instead of writing C# directly?
Calor adds a source language and compiler step to a .NET workflow. You gain declared effects, contracts in the syntax, and optional stable editing IDs. You also take on an unfamiliar language, another compiler boundary, and interop configuration. These mechanisms are not evidence that it reduces total cost or defects. Design Principles explains those choices; this page helps you decide whether they fit your work.
Start with the requirement, not a benchmark score
| Your requirement | Decision to evaluate |
|---|---|
| Enforce declared effects on supported Calor paths | Try a small module whose external calls have known effect coverage. Review all waivers and manifests. |
| Check preconditions and postconditions | Compare Calor's runtime modes and supported proof model with ordinary C# validation and tests. |
| Address edits by stable identity | Try explicit IDs on selected targets, then check that your editing workflow preserves them. |
| Keep familiar source, libraries, and debugging tools | Writing C# directly avoids the translation step and may be simpler. |
| Prove properties outside Calor's modeled contracts | Evaluate a proof assistant or domain-specific verification tool instead. |
An ID supplies a named target. Whether that improves real editing accuracy remains a workload-dependent hypothesis.
Contracts and effects are not a complete specification. A compiler check cannot establish correctness of arbitrary business behavior or external libraries. Keep the verification limits beside any decision that depends on those checks.
Account for integration and review costs
Calor emits C#, so existing .NET libraries remain available. Their effect coverage may need manifests, and unsupported migration syntax may be preserved as raw C# rather than analyzed as Calor. Inspect generated code and diagnostics before expanding adoption. See effect manifests and imports.
Human reviewers still need to read the source. Prefix expressions and indentation may be unfamiliar, even when an agent writes the file. Try the account-free first program and review one real change with the people who would maintain it. Provider integration is optional; it does not remove correctness ownership.
The CLI and language server support checking and editing. Verify the features your editor/client actually enables rather than assuming parity with C#'s tooling. Existing-project setup belongs in the getting-started guide.
Measure your own workload
Source size depends on the actual programs and tokenizer. There is no universal token premium or saving implied by prefix syntax. Record source versions, tokenizer/version, task inputs, and behavioral equivalence before comparing context cost.
The published static source pairs are not all behaviorally equivalent. Their calculator ratios do not establish language quality or agent productivity. Consult the dated snapshot and limits instead of treating a score table as an adoption recommendation.
For a local evaluation, record installation effort, review time, diagnostic handling, test outcomes, and costs under both workflows. A failed or inconclusive comparison is useful evidence. Do not replace missing evidence with a claim that a model understands one syntax better.
The adoption playbook gives a bounded integration path. The research evidence status records the historical M0 administrative stop and the current paused PP-W study; it supplies no production-safety or demand guarantee.