functional-programming
/functional-programming
Modeluje domenę tak, by niedozwolonych stanów nie dało się zbudować, rozdziela logikę czystą od wejścia i wyjścia oraz przepisuje kod z zachowaniem znaczenia.
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 10
Brak sygnałów. Repozytorium zmienione 09.11.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Modeluje domenę tak, by niedozwolonych stanów nie dało się zbudować, rozdziela logikę czystą od wejścia i wyjścia oraz przepisuje kod z zachowaniem znaczenia.
Oryginalny opis (EN)
Model a domain so its illegal states cannot be constructed — functional-programming discipline. Use when a domain model has many variants or illegal states to rule out, when an implicit state machine hides in scattered flags or optional fields, when code mixes pure logic with I/O, when a rewrite must preserve semantics, or the user asks for FP style.
Jak działa
- Gotchas — observed failures
Podgląd SKILL.md
--- name: functional-programming disable-model-invocation: true description: "Model a domain so its illegal states cannot be constructed — functional-programming discipline. Use when a domain model has many variants or illegal states to rule out, when an implicit state machine hides in scattered flags or optional fields, when code mixes pure logic with I/O, when a rewrite must preserve semantics, or the user asks for FP style." --- # Functional programming Choose representation by the task's axis — functions for open-ended behavior, algebraic data for closed variant sets; when a function value must cross a serialization or IPC boundary, defunctionalize it into a data tag plus an `apply` dispatch ([defunctionalization](https://en.wikipedia.org/wiki/Defunctionalization)). The discipline, in the order a modeling or refactoring task meets it: 1. **Make illegal states unrepresentable.** Stacked optional fields or booleans (primitive obsession — Fowler & Beck, *Refactoring*) leave illegal combinations constructible. Define the data variants *before* the function — sum and product types, one branch per variant, structural recursion where the data is self-referential, total functions, exhaustive matching — and parse into precise types once at the boundary. Prefer parametric signatures so the implementation cannot special-case a representation ([Wadler, Theorems for Free!](https://doi.org/10.1145/99370.99404), FPCA 1989). Keep a wish list of pure helpers (name, signature, one-line purpose). ([Minsky, Effective ML Revisited](https://blog.janestreet.com/effective-ml-revisited/); [Wlaschin](https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable/); [Haskell 2010 Report §4.2.1](https://www.haskell.org/onlinereport/haskell2010/haskellch4.html)) 2. **Non-trivial domain → model it in Haskell first.** ADTs for variants, total functions for rules, exhaustive matching for coverage — get it compiling before writing production code ([Brady, Type-Driven Development](https://www.manning.com/books/type-driven-development-with-idris); correctness by construction — Hall & Chapman, *IEEE Software* 19(1), 2002). The compiled model is the executable spec; port it preserving its types, so a divergence between model and code is a bug, not a style choice. 3. **Functional core, imperative shell.** Branching and domain rules live in a pure value-in/value-out core glued with higher-order combinators (`map`/`filter`/`fold`/`flatMap`); I/O, mutation, time and randomness live in a thin outer shell ([Bernhardt](https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell)). Default to persistent data structures — updates return structurally shared new versions, rollback is a pointer (Okasaki, *Purely Functional Data Structures*, 1998). Unobservable local mutation preserves referential transparency; reach for free monads or effect ASTs only when you need multiple interpreters. Keep operations orthogonal — mechanism, not policy, with no hidden cross-state coupling ([Raymond, TAOP ch.4](http://www.catb.org/esr/writings/taoup/html/ch04s02.html)); hide change-prone decisions behind narrow module boundaries ([Parnas, CACM 1972](https://doi.org/10.1145/361598.361623)). 4. **Every rewrite preserves semantics** — across all valid inputs, evaluation order, cancellation and lifetimes; semantic transparency is what makes a transform legal rather than a rewrite that happens to pass ([Leroy, CompCert, CACM 2009 §1](https://xavierleroy.org/publi/compcert-CACM.pdf)). When the rewrite is a compiler/IR lowering — constructs `C` into primitives `P` under combinators `K` — every `c ∈ C` needs a finite lowering into the subuniverse generated by `P`; drop a primitive only when the remaining primitives express it or the primitive set's owner signs off. ## Gotchas — observed failures - Extract typeclasses or higher-kinded abstractions only after several concrete types share the shape. - In hot loops, keep functional structure without per-iteration closure or combinator allocations. - Keep fault recovery in an external supervisor rather than inside pure domain types.
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · hebtcd/skills | 90 | MIT |
| Tyler-R-Kendrick/agent-skills | 100 | MIT |
Migawka bazy z 13.11.2026 · wersja paczki 07e24e7e1453 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 0 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 90principle-model-the-domain
Zapisuje reguły domeny w maszynie stanów, typowym modelu lub tabeli, tak by nieprawidłowych stanów nie dało się zbudować. - 86principle-type-system-discipline
Przerabia typ, który dopuszcza niepoprawne kombinacje pól, na osobne warianty, tak by takich stanów nie dało się wyrazić. - 86principle-type-system-discipline
Projektuje typy tak, by nielegalnych stanów nie dało się zapisać: brandowane prymitywy, parsowanie na granicach i pełne warianty. - 86principle-type-system-discipline
Projektuje typy tak, by nielegalnych stanów nie dało się zapisać, parsuje dane zewnętrzne na granicach, wyczerpuje warianty i wyprowadza typy z autorytatywnych schematów. - 86principle-type-system-discipline
Projektuje typy tak, by nielegalnych stanów nie dało się zapisać, parsuje dane zewnętrzne na granicach, wyczerpuje warianty i wyprowadza typy z autorytatywnych schematów. - 86principle-type-system-discipline
Projektuje typy tak, by nielegalnych stanów nie dało się zapisać, parsuje dane zewnętrzne na granicach, wyczerpuje warianty i wyprowadza typy z autorytatywnych schematów.