Inconsistencies#

Where Temper's documentation disagrees with itself, with temperlang.dev, with Temper's first compiler (written in Kotlin), or with tempest, found while gathering the docs here (2026-11-07). Each is flagged in place with a > **Note:** that links here. Resolve one by fixing the docs, the compiler, or both; then remove its note and its entry.

Where tempest differs from the Kotlin compiler on purpose, or works around its bugs, is in notes/kotlin-differences.md; this page doesn't repeat those.

Licensing and community#

I1: The documentation's license#

• Docs: COPYRIGHT, in both repositories, and temper license say the documentation is CC BY-SA 4.0.
• Site: temperlang.dev's footer, from its mkdocs.yml, links CC BY-NC-SA 4.0 (non-commercial).
• Suggested: BY-SA, as COPYRIGHT says; fix the footer. These docs follow COPYRIGHT (NOTICE).

I2: Discord invites#

• Docs: the Kotlin repository's README and CONTRIBUTING link discord.gg/QQKgZMukVB, the site's footer discord.gg/TY3Be6fzwu, and the tour discord.com/invite/6Jb83cq5FH.
• Here: every page uses the site's, TY3Be6fzwu.
• Suggested: check which still work, make one permanent, and use it everywhere.

I11: Playground addresses#

• Here: every link to try Temper (the README, the guide, and tools) goes to tempest's playground, published on GitHub Pages with the docs site. play.temperlang.dev is left only where it's history: the internals' comparison with Temper's first playground.
• Left: the playground terms still name playground.temper.systems, the old site's playground, and the Kotlin README still links play.temperlang.dev.
• tempest: a static page, compiling in the browser, with no server and no accounts; sharing puts the code in the URL.
• Suggested: terms that fit what it does (a static page may need few or none), the Kotlin README's link updated, and one lasting address.

Languages and versions#

I3: C++ support#

• Docs: the Kotlin README lists C++ under "Coming soon"; the target language list leaves it out; the tour lists six languages.
• tempest: C++ passes every functional test, and real libraries' tests, under sanitizers.
• Kotlin: has a cpp backend (not built by default), failing some functional tests.
• Suggested: list C++ as supported, built with -b cpp; done in target languages and the tour.

I4: Backends that tempest doesn't have#

• Docs: the target language list documents java8, mypyc, and data; builtins document dataFile, which writes through data; temper build builds data by default; the test matrix has cppv.
• tempest: none of these; dataFile isn't declared.
• Suggested: decide which matter. Java 8 has users in older JVMs; mypyc and cppv are experiments; data needs dataFile.

I5: Node and JavaScript versions#

• Docs: getting started says Node 14 or later; the 0.x release note "Require Node 18 and Python 3.11" says 18; the target language list says ES2018.
• tempest: CI runs generated JavaScript on Node 24, and checks it with the latest TypeScript.
• Suggested: state one tested range, such as Node 18 and later, and test the oldest in CI.

I13: Lua versions#

• Docs: "Supported version: Lua 5.1".
• tempest: rockspecs declare lua >= 5.1; tests run on Lua 5.4 and LuaJIT, not PUC Lua 5.1; a few functional tests need 5.3 or later.
• Suggested: say "5.1 and later, tested on 5.4 and LuaJIT", and list what needs 5.3.

I14: Python named arguments#

• Docs: the Python notes said named arguments translate to Python's, but with numeric suffixes still to remove.
• Both compilers: named arguments were removed from Temper (see the release notes); tempest writes no numbered names.
• Here: the note is replaced by how names translate.

I15: Contributor toolchains#

• Docs: the Kotlin CONTRIBUTING asks for JDK 21, Java 8 and 17, Maven, Lua 5.1 or 5.4, .NET 6, Node 18, Python 3.11, and Rust 1.71.1.
• tempest: Rust 1.85.0, uv, and each language's tools to run every backend's tests (contributing).
• Suggested: each repository keeps its own list; no change needed until the Kotlin repository retires.

Output and tools#

I6: The temper.out layout#

• Docs: getting started listed csharp/hello/src/Hello/HelloGlobal.cs, java/hello/src/main/java/hello/hello/HelloGlobal.java, and lua/hello/hello.lua.
• tempest: src/HelloGlobal.cs, src/main/java/hello/HelloGlobal.java, and init.lua; its layout is tested against the Kotlin compiler's current one.
• Here: the list shows tempest's paths.

I7: Rust warnings#

• Docs: generated Rust "still causes a number of compiler warnings", silenced with --cap-lints=allow.
• tempest: its Rust passes cargo build and clippy without warnings.
• Suggested: drop the advice once tempest's output is what users get.

I8: Numbered names in output samples#

• Docs: the home page's translations, made by the Kotlin compiler, had names like x__4 and this__0.
• Here: the introduction shows tempest's translations, regenerated, with the source's names.

I9: The command line#

• Docs: the guide uses temper init, build, test, watch, repl (and its describe), version, and help; the language server is temper serve --port N.
• tempest: temper's commands and flags, as tempest build, test, run, repl, init, version, license, licenses, help, and serve (or lsp, on standard input and output only); no watch, doc, or repl -b yet, which say so, and the REPL has no describe, translate, or help functions yet (the command line, the REPL).
• Suggested: finish CLI parity, then decide whether the binary is called temper.

I12: The functional test matrix#

• Docs: the Kotlin repository's functional-test-matrix.md, generated, shows failures on cpp, cppv, lua, and others.
• tempest: all 72 functional tests pass on the interpreter and on every backend.
• Suggested: not imported here; regenerate it there, or retire it when tempest takes over.

Language and examples#

I10: Examples tempest doesn't run as marked#

The reference's examples carry the result the Kotlin compiler gave when its docs were generated, and compat/check_doc_examples.py runs them with tempest (writing these docs). These 14 disagree; each was checked on the Kotlin compiler, which runs them as marked. Each has a <!-- known: I10 --> comment before its fence, so the checker, which runs in CI, counts it as known.

Suggested: fix tempest for each, or record a deliberate difference in notes/kotlin-differences.md, and remove its known comment and its row here.

I16: A function expression used as a declaration#

• Docs: the literate example in modules declared fn greet(…) { … } and later called greet("world"); but a function expression's name isn't visible outside it, as builtins explain.
• Here: it's let greet(…).

I17: The tour's date snippets#

• Docs: the tour's Person uses Date, without an import, and its C#, Java, JavaScript, Lua, and Python snippets construct new Date(1987, 6, 5) from the library.
• Both compilers: std/temporal's Date is each language's own date type (DateTime, LocalDate, JavaScript's Date, whose months count from 0, and datetime.date).
• Suggested: import std/temporal in the Temper code, and use each language's date in the snippets.

I18: for … of loops#

• Docs: tutorial 3 says "for each" looping is future work (issue 20).
• Both compilers: for (let x of list) { … } works, with break and continue, since 0.4.0 (see the release notes).
• Suggested: teach for … of in tutorial 3.

I19: Module prefaces and ;;;#

• Docs: modules describes a module preface, module parameters, and up to two ;;; tokens: preface, body, then JSON metadata.
• Both compilers: one ;;; separates code from JSON metadata after it (tempest follows the Kotlin compiler's splitCodeFromMetadata); there are no prefaces or parameters (issue 10).
• Suggested: document ;;; as it works, and keep prefaces as a plan.

I20: Top-level statements run out of order#

• Docs: three builtins examples log a top-level var before and after assigning it, as source order would.
• Both compilers: log the value after every assignment, twice, since a module's top-level readers of a var wait for every statement that assigns it; inside a function, they log as shown.
• Suggested: settle top-level order, which notes/kotlin-differences.md ("Top-level statements in source order") calls broken; until then, move the examples into a function.

I21: Date.yearsBetween with the later date first#

• Docs: std/temporal's doc comment says the result is the floor of the range's magnitude, so the order of the dates shouldn't matter.
• Both compilers' interpreters: Date.yearsBetween(2026-03-01, 2024-02-29) is -3, though the other order gives 2.
• Suggested: fix std to match its comment (and check each backend's connected version, such as Java's ChronoUnit.YEARS.between), or document it as signed.

I22: Named groups in regular expressions#

• Docs: std's regex docs write a capture as /(?<name>...)/ and, a few lines later, /(?name = ...)/; the tutorial uses (?name=…).
• Kotlin: accepts both.
• tempest: accepts only (?name=…): lookaround and (?<name>...) aren't supported; use (?name=pattern).
• Suggested: accept (?<name>…) in tempest too, since JavaScript, Java, C#, and Python 3.11's re (as (?P<name>…)) users expect it.

I23: Integer literals too big for Int32#

• Docs: four builtins examples, >>, >>>, ^, and ~, write 64-bit hex or 32-bit binary literals without i64, such as 0x8000_0000_0000_0000 and 0b1111_0000_….
• Both compilers: read them as Int32, warn that they're out of bounds, and wrap them (hex up to 0xFFFF_FFFF is exempt, as bits; binary isn't). The ^ and ~ examples still hold after wrapping; the shifts compare wrapped values.
• Suggested: decide whether integer literals take their type from context; then add i64, or write the 32-bit ones in hex, as the answer needs.

I24: Tutorial examples tempest doesn't run#

The tutorial's REPL transcripts run as a test (crates/temper-frontend/tests/repl_docs.rs); two of control flow's examples are left out of it, as tempest rejects them:

• let areaPerPerimeter = fn (shape: Shape): Float64 { … }: "needs a declared type, such as a @fun interface, since a function literal takes its type from the type wanted" (language.md, fun interfaces).
• do(fn () { … while(i < n, fn { … }); }): "Use of builtin do is malformed".

Suggested: decide whether tempest should accept them, or show what it accepts in the tutorial.