Glossary
Terse, exact definitions of Bynk’s load-bearing terms. Each links to its fuller reference page where one exists.
A keyed, stateful entity whose state lives in store fields and changes only
through writes inside its handlers. See Agents.
context
Section titled “context”A bounded context: an isolated module with its own services, agents, and provided capabilities, reachable only across an explicit boundary.
service
Section titled “service”A named group of handlers (on call, from http, from cron, from queue) declared
inside a context. See HTTP.
capability
Section titled “capability”An interface of effectful operations a context may depend on. See Capabilities & providers.
provider
Section titled “provider”A provides block implementing a capability, optionally given other
capabilities it uses. See Capabilities & providers.
commit
Section titled “commit”The atomic persistence of a handler’s store writes. A handler’s := writes are
staged and committed together when it returns, after invariants are checked; a
faulting handler commits nothing. See Agents.
branded type
Section titled “branded type”A compiled type carrying a unique tag so values of distinct Bynk types cannot be interchanged in the emitted TypeScript; how opaque types stay distinct. See Emission.
opaque type
Section titled “opaque type”A type whose representation is hidden outside its defining module; constructed and inspected only through its API. See Type system.
refined type
Section titled “refined type”A base or named type narrowed by a where predicate, e.g. Int where Positive.
See Refined-type API.
sum type
Section titled “sum type”A tagged union of variants, each optionally carrying a payload. See Type system.
record
Section titled “record”A product type of named fields, each with a type and optional default. See Type system.
A sum type whose variants all carry no payload. See Type system.
refinement predicate
Section titled “refinement predicate”A built-in constraint used in a where clause (Positive, NonNegative,
InRange, Matches, MinLength, …). See Refined-type API.
admission
Section titled “admission”The compile-time rule by which a literal that provably satisfies a refined type’s
predicate is accepted directly (lowering to .unsafe), with no Result. See
Refined-type API.
.of / .unsafe
Section titled “.of / .unsafe”Constructors for a refined type: .of validates at run time and returns a
Result; .unsafe constructs without a check. See
Refined-type API.
zeroable
Section titled “zeroable”A type with a defined implicit zero value, letting an agent state field omit an initialiser. See Agents.
Effect
Section titled “Effect”The type of a computation that performs effects; produced by handlers and
capability operations and sequenced with <-.
Result / Option
Section titled “Result / Option”Errors-as-values types: Result is Ok or Err; Option is Some or None.
See Type system.
Duration
Section titled “Duration”A base type for a span of time, written as a unit literal (5.minutes); composes
with Instant. See Type system.
Instant
Section titled “Instant”A base type for an absolute point in time, minted by Clock.now(); no literal,
orderable but not numeric, advanced by a Duration. See
Type system.
A lazy read over a store’s storage, carrying the same combinator vocabulary as
the eager List methods but dispatched by receiver provenance; non-storable and
non-boundary. See Type system.
Mock[T]
Section titled “Mock[T]”A test-only expression that fabricates a value of type T, optionally pinned to a
chosen value. See Testing.
project vs legacy mode
Section titled “project vs legacy mode”Project mode is a bynk.toml-driven directory layout (a src/tests split,
bynkc test); legacy mode compiles a single .bynk file as a standalone unit,
with no manifest. See bynk.toml manifest.