Origin & History
CGPA (Cat Girl Program Analysis) was founded in 2018 by GaloisCat, a PL researcher with a deep obsession with fixpoint lattices, a mild obsession with catgirls, and a burning frustration that every existing online venue for program analysis discussion was either dead, overrun by practitioners who'd never read the primary literature, or maintained by someone who thought if (x != null) counts as "static analysis."
The forum launched with three subforums, twelve registered users, and a single pinned post titled "Read Cousot & Cousot 1977 Before Posting. No Seriously." That post remains pinned to this day. Over the years, CGPA has grown into one of the more active corners of the internet for rigorous, citation-backed discussion of programming language theory and program analysis.
The name is, yes, a triple pun: it references GPA (grade-point average), the field of Program Analysis, the aesthetic of cat girls, and, for those who know their abstract algebra, the loose structural analogy between Galois connections and the soundness conditions of abstract interpretation. GaloisCat insists this was intentional. The community has reached a polite consensus on plausible deniability.
What We Discuss
CGPA focuses on the rigorous, mathematically-grounded side of program analysis. Our primary subject areas:
🔬 Abstract Interpretation
Our flagship topic. Abstract interpretation is a framework for computing sound over-approximations of program behavior by mapping concrete semantics into abstract domains. The Cousot & Cousot 1977 paper — "Abstract Interpretation: A Unified Lattice Model for Static Analysis of Programs by Construction or Approximation of Fixpoints" — is considered required reading before posting in this subforum. No exceptions. The paper introduced the foundational framework of using Galois connections between concrete and abstract domains to guarantee soundness.
λ Type Theory
Discussion of dependent types, substructural type systems, gradual typing, bidirectional type checking, and the metatheory of type systems. Strong preference for posts that come with proofs or at minimum proof sketches. Idris, Coq, Agda, and Lean discussions welcome. Asking "why doesn't TypeScript count as a dependent type system" will get you a very patient, very long reply.
📊 Dataflow Analysis
Classical monotone framework dataflow, interprocedural analysis, pointer analysis, taint tracking. Kildall's algorithm gets its own pinned thread. We ask that you understand the lattice-theoretic foundations before proposing "improvements" to known algorithms.
✅ Formal Verification
Model checking, theorem proving, separation logic, Hoare logic, refinement types. Discussion of industrial tools like SLAM, Infer, Astrée, and Frama-C is welcome, provided you also know why they work. The Ariane 5 rocket failure remains an evergreen example.
On The "Cat Girl" Theming
Let's be direct: the cat girl aesthetic is purely cultural and aesthetic, borrowed from internet subcultures that GaloisCat was part of when founding the forum. It is not a gatekeeping mechanism, a gender requirement, or anything other than a vibe.
All genders are welcome. All backgrounds are welcome. What is required is: good faith engagement with the theory, willingness to read primary sources, and basic intellectual humility. The forum's unofficial motto is "cute AND rigorous," and that second part is load-bearing.
Cat-ear avatars are encouraged but not mandatory. Rigor is mandatory. The two are not in conflict.
Community Norms & Rules
-
§1
Read the paper first.
Before arguing about any algorithm, framework, or result — read the original paper. Not a blog post about it. Not a Stack Overflow answer. The paper. This rule was written specifically because of an infamous 2019 thread in which someone argued for fifteen posts that "widening is unnecessary" without having read the definition of widening. -
§2
Cite your sources.
Claims require references. "I heard that" and "I think" are fine for hypotheses. For assertions, link a paper, a spec, or a proof. ACM DL, arXiv, DBLP, and ECCC are your friends. -
§3
Be rigorous, not pedantic.
There is a difference between being precise (good) and being a jerk about notation choices (bad). If someone writes ⊑ when you'd write ≤, engage with the substance. The moderators will interpret bad-faith pedantry as a rules violation. -
§4
Be excellent to each other.
Discrimination of any kind is not tolerated. The forum's demographics skew toward people who've been excluded from "serious" academic spaces for reasons unrelated to their technical ability. We aim to be the opposite of that. -
§5
No vague tool recommendations.
"Just use Coverity" or "just use Z3" without explaining why, what soundness guarantees it provides, or what its limitations are will be moved to the Practitioner Corner subforum. This is a theory forum first. -
§6
The Cousot Clause.
Specifically regarding abstract interpretation: if you have not read Cousot & Cousot 1977 and Cousot & Cousot 1979 (POPL), your post will be held in a moderation queue until a moderator judges that the question could not have been answered by reading those papers. We are not sorry about this.
Hall of Fame: Notable Threads
These threads are archived and considered foundational reading for new members.
Recurring Events
Staff & Moderators
| Username | Role | Subforums | Known For |
|---|---|---|---|
| GaloisCat | Founder | All | Abstract interpretation, Galois connections, refusing to let the Cousot Clause be removed |
| LambdaLass | Admin | Type Theory, Formal Verification | Gradual typing, logical relations proofs, the famous 512-reply thread |
| FixpointFerret | Moderator | Abstract Interp, Dataflow | Widening operators, chaotic iteration, instigating the 2019 widening debate |
| HeapHuntress | Moderator | Formal Verification | Separation logic, concurrent program verification, Iris framework |
| MonadMew | Moderator | Type Theory | Effect systems, monadic semantics, writing the "don't ask about Haskell monads as burritos" sticky |
Technical Infrastructure
CGPA is powered by Rabbithole, an AI-driven web generation system that builds pages on demand. Each page of this forum is generated independently and cached, meaning the site is essentially a living document that grows as you explore it. Rabbithole is an open-source project — if you're curious about the infrastructure, check out the GitHub repository.
The irony of a program analysis forum running on a system that generates its own IR on the fly is not lost on us. GaloisCat has suggested we write a formal semantics for page generation. The suggestion has been tabled pending definition of the abstract domain.