docs: record why {} is a set and {:} is a map - #21
Conversation
The collections design doc described nesting and reference counting but said
nothing about literals, so the one genuinely non-obvious decision - that brace
syntax is shared between map and set, and how Mux breaks the tie - was written
down nowhere.
Explain the tradeoff: the compiler used to infer which one `{}` meant from the
expected type, which required a third EmptySetOrMap type threaded through
semantics and codegen plus a span-keyed override map, and still had no answer
when there was no expected type. `{:}` resolves it in the grammar instead.
|
| Filename | Overview |
|---|---|
| docs/design/collections.md | Adds a new "Empty literals" section explaining the {} = set, {:} = map rule, the removed EmptySetOrMap inference machinery, and three practical consequences; content is accurate and uses ASCII-only prose. |
| llms.txt | One-line description update for the Collections entry to include the new empty-literals topic; kept in sync with the doc as required. |
Reviews (2): Last reviewed commit: "docs: index the empty-literal rule in ll..." | Re-trigger Greptile
llms.txt is how agents decide which doc to open, so a rule that is not named in the description is a rule they will not find. The collections entry listed BTree and nesting but not literals.
|
1 participant
Design-doc half of the fan-out for muxlang/mux-compiler#266.
docs/design/collections.mdcovered implementations, BTree-vs-hash, nesting, and reference counting - but said nothing about literals. So the one genuinely non-obvious decision in Mux's collections (map and set share brace syntax, and something has to break the tie) was recorded nowhere.This repo's job is the reasoning no single code repo owns, and this is a good example: the rule lives in the compiler, but the tradeoff does not belong there.
Adds a section covering:
{}is always the empty set, the empty map is{:}{}meant from the expected type, which needed a thirdType::EmptySetOrMapthreaded through semantics and codegen plus a span-keyed override map that rewrote the type after the fact. It worked, but the ambiguity leaked into both stages, and an empty literal with no expected type had no answer at all.{}in map position is an error rather than an inference, empty literals still need an explicit type, and nesting follows the rule per position (map<int, set<int>> x = {1: {}}vsmap<int, map<int, int>> y = {1: {:}})Companion PRs: muxlang/mux-website#29 (user-facing docs), muxlang/mux-compiler#270 (changelog).
🤖 Generated with Claude Code