Reference¶
This reference documents every module, function, and type in fptk. Each page explains the underlying functional programming concepts, how the implementation works, and provides practical examples.
Module Overview¶
Core Functions¶
fptk.core.func — Function combinators for composing and transforming functions.
| Function | Purpose |
|---|---|
pipe |
Thread a value through functions left-to-right |
compose |
Combine functions right-to-left (mathematical notation) |
curry |
Transform multi-arg functions into chains of single-arg functions |
flip |
Swap the first two arguments of a function |
tap |
Execute side effects without breaking data flow |
thunk |
Lazy, memoized computation |
identity |
Return input unchanged |
const |
Ignore arguments, always return the same value |
once |
Run a function at most once |
try_catch |
Convert exceptions to Result values |
Algebraic Data Types¶
These types model common patterns in a type-safe, composable way.
| Type | Module | Purpose |
|---|---|---|
Option |
fptk.adt.option |
Explicit absence handling (replaces None checks) |
Result |
fptk.adt.result |
Typed error handling (replaces exceptions) |
Reader |
fptk.adt.reader |
Dependency injection via environment threading |
State |
fptk.adt.state |
Pure stateful computations |
Writer |
fptk.adt.writer |
Log accumulation alongside computation |
NonEmptyList |
fptk.adt.nelist |
Lists guaranteed to have at least one element |
Operations on Collections¶
| Module | Purpose |
|---|---|
traverse |
Sequence and traverse for Option/Result collections |
validate |
Applicative validation (accumulate all errors) |
lazy |
Memory-efficient lazy iterator operations |
async |
Async utilities for concurrent Result operations |
How to Read These Pages¶
Each reference page follows a consistent structure:
- Concept — What functional programming idea this implements and why it matters
- API — Types, functions, and their signatures
- How It Works — Implementation details and design decisions
- Examples — Practical code showing common usage patterns
- When to Use — Guidance on appropriate use cases
Quick Links by Use Case¶
"I want to handle missing values without None checks"
→ Option
"I want typed errors instead of exceptions"
→ Result
"I want to chain transformations cleanly"
→ pipe, compose
"I want dependency injection without passing config everywhere"
→ Reader
"I want to track state changes purely"
→ State
"I want to accumulate logs during computation"
→ Writer
"I want to validate and collect all errors"
→ validate_all
"I want to process large data without loading it all in memory"
→ lazy iterators
"I want to run async operations and combine their results"
→ async tools