Skip to content

Commit 7d2121b

Browse files
committed
docs: add STYLE.md (initial stub for M4 refinement)
Adds a first draft of docs/STYLE.md documenting the conventions agda-algebras currently follows, with explicit flags for the axes where style decisions remain open (naming conventions, notation table, universe-level variable scope). The style guide is deliberately short at this stage. Applying and refining it across Setoid/ and Classical/ is tracked in M4-1, and the document will grow as specific decisions are settled. A premature full-length style guide would codify decisions that are properly made during the M4 sweep. Addresses #253 (M1-4).
1 parent 5265f71 commit 7d2121b

1 file changed

Lines changed: 129 additions & 0 deletions

File tree

docs/STYLE.md

Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
<!-- File: docs/STYLE.md -->
2+
3+
# agda-algebras Style Guide
4+
5+
This document describes the conventions that the `agda-algebras` library follows. It is a living document: when the library adopts a new convention, this file changes. When it describes a convention that the library doesn't actually follow, it's wrong — the code is the ground truth, and the style guide chases it.
6+
7+
The long-tail work of applying this guide consistently across `Setoid/` and `Classical/` is tracked in [#M4-1](https://github.com/ualib/agda-algebras/issues). This document is the reference for that sweep; it will be refined as specific axes are settled.
8+
9+
---
10+
11+
## File format
12+
13+
Every Agda source file begins with:
14+
15+
```agda
16+
{-# OPTIONS --cubical-compatible --safe --exact-split #-}
17+
```
18+
19+
followed, on the next non-comment line, by the module header. The module name must match the filename (with `/` replaced by `.` under the `src/` include root): `src/Base/Algebras/Basic.agda` contains `module Base.Algebras.Basic where`.
20+
21+
Exceptions:
22+
23+
+ `src/Legacy/Base/` retains its historical `--without-K` pragma. New contributions do not belong in this tree.
24+
+ `src/Everything.agda` is generated by the Makefile; do not edit it directly.
25+
26+
## Module structure
27+
28+
+ One concept per module, where feasible. A module called `Congruences` should be about congruences. When a module grows large enough to warrant subdivision, make the subdivision along mathematical lines, not lines of implementation convenience.
29+
30+
+ Module headers name the mathematical object being developed, not the technical construction (`Setoid.Algebras.Congruences` over `Setoid.Algebras.Records.QuotientRecords`).
31+
32+
+ Re-exports use `open import X public` at the top of an umbrella module, with imports grouped into blocks (stdlib, then internal, with a blank line between).
33+
34+
+ Classical algebraic structures follow the Signatures / Theories / Structures / Bundles / Small quintuple pattern (see [#253's M3-1 description](../blob/master/docs/GITHUB_PROJECT.md) for the reasoning).
35+
36+
## Imports
37+
38+
+ Prefer tight `using (...)` clauses over bare `open import X`.
39+
40+
+ Group imports into blocks with blank lines between: Agda primitives, stdlib, internal modules. Within each block, alphabetize.
41+
42+
## Naming
43+
44+
The library has some established conventions and some open questions.
45+
46+
**Established**:
47+
48+
+ Types start with uppercase: `Algebra`, `Congruence`, `Homomorphism`.
49+
+ Level variables are lowercase Greek: `α`, `β`, `ρ`, ``.
50+
+ First/second projections of Σ-types are `∣_∣` and `∥_∥` rather than `proj₁` / `proj₂` (a long-standing agda-algebras idiom carried over from the Escardó style).
51+
52+
**Not yet settled** (tracked in M4-1):
53+
54+
+ Whether predicates are named `IsX` (matching stdlib idiom) or `is-X` (matching some parts of the existing code). Until settled, follow local convention.
55+
+ The scope of universe-level variables `𝓞` and `𝓥` (design-discussion in #M4-3).
56+
57+
When in doubt, follow the convention of the surrounding code and ask in the PR.
58+
59+
## Notation
60+
61+
Notation in agda-algebras is Unicode-heavy and largely inherited from Escardó-style type-theory developments. A canonical symbol table will land as part of M4-1.
62+
63+
Pending that, the rules of thumb are:
64+
65+
+ Do not introduce new notation for a concept that already has notation elsewhere in the library.
66+
+ If you're adding notation for a new concept, make it consistent with the surrounding idioms.
67+
+ Avoid overloading single Unicode characters with multiple meanings.
68+
69+
## Record vs Σ
70+
71+
+ The core `Algebra` type is a record. This was an early design choice and remains canonical.
72+
+ Classical algebraic structures (`Semigroup`, `Monoid`, etc.) are Σ-typed at the core, with record-typed bundle views for stdlib interop (ratified in ADR-002, to land with M3-1).
73+
+ When adding a new structure, the default is: record for foundational types that will be inhabited many times and benefit from named projections; Σ for theories-over-an-algebra whose mathematical meaning is "an algebra equipped with a proof it satisfies a theory."
74+
75+
## Proof style
76+
77+
+ Prefer many small focused theorems over few large ones. A theorem whose proof is more than about 20 lines should usually be restructured as two or three lemmas.
78+
79+
+ Named helper lemmas over `where`-clauses and opaque rewrite chains. A named lemma becomes part of the library's training corpus; a `where`-clause does not.
80+
81+
+ Explicit type signatures on every public definition. Not just the ones Agda cannot infer: the ones humans will want to read.
82+
83+
+ Equational reasoning with `≡⟨ ⟩` / `≈⟨ ⟩` notation is preferred over manual `trans` / `sym` chains when feasible.
84+
85+
## Comments and documentation
86+
87+
agda-algebras is intended to serve as a high-quality corpus of Agda proofs for machine-learning work. Comments are first-class artifacts, not afterthoughts.
88+
89+
Every public definition should have a prose comment block immediately above it explaining:
90+
91+
+ What the definition is, in the same terms a mathematician would use.
92+
+ When one would use it, in terms of mathematical motivation.
93+
+ Cross-references to related definitions (the closest mathematical neighbors, not everything possibly related).
94+
95+
Example:
96+
97+
```agda
98+
-- | `Hom 𝑨 𝑩` is the type of homomorphisms from 𝑨 to 𝑩. A homomorphism
99+
-- | is a function on carriers that commutes with every basic operation of
100+
-- | the signature. See also: `IsHomomorphism` for the predicate form,
101+
-- | and `Base.Homomorphisms.Isomorphisms` for the isomorphism variant.
102+
Hom : (𝑨 : Algebra α) (𝑩 : Algebra β) → Type _
103+
Hom 𝑨 𝑩 = ...
104+
```
105+
106+
These prose comments are not decoration — they are part of the training data the library aspires to produce. Treat each one as a short paragraph that would help a mathematician approaching this concept for the first time.
107+
108+
## Deprecation
109+
110+
The public API stability policy: breaking changes to names or signatures in publicly-exported definitions go through at least one minor-version deprecation cycle. Internal helpers (not re-exported from umbrella modules, not documented) can change without notice.
111+
112+
To deprecate a public definition:
113+
114+
1. Add the new form.
115+
2. Mark the old form with a `{-# WARNING_ON_USAGE ... #-}` pragma explaining the replacement.
116+
3. Announce in `CHANGELOG.md` under `### Deprecated`.
117+
4. Remove the old form no sooner than the next minor version.
118+
119+
## References
120+
121+
+ The full milestone roadmap: [`docs/GITHUB_PROJECT.md`](GITHUB_PROJECT.md).
122+
+ Architecture Decision Records: [`docs/adr/`](adr/) (scaffolding tracked in #M1-6).
123+
+ Contributor workflow: [`CONTRIBUTING.md`](../CONTRIBUTING.md).
124+
125+
---
126+
127+
*This document is incomplete by design. It will be refined as specific style decisions are settled in M4. Contributions to STYLE.md itself are welcome, particularly if you encounter an undocumented convention while working on the library.*
128+
129+

0 commit comments

Comments
 (0)