Przejdź do treści
Biblioteka skilli
Programowanie · Budowanie i kod

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.

Repozytorium
skills ↗
Licencja
MIT
Ostatnia zmiana repozytorium
09.11.2026

Ocena i bezpieczeństwo

90/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść25 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
10
Przestarzałość

Brak sygnałów. Repozytorium zmienione 09.11.2026, bez odwołań do wycofanych modeli i API.

Licencja

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

  1. Gotchas — observed failures
Sekcje z nagłówków SKILL.md, w oryginale · 18 linii, 444 słów
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

RepozytoriumWynikLicencja
Ta strona · hebtcd/skills90MIT
Tyler-R-Kendrick/agent-skills100MIT

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.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.