effect 4.0.0-beta.77 → 4.0.0-beta.79

package/src/Runtime.ts

@@ -1,59 +1,11 @@
 /**
- * Runtime helpers for turning an `Effect` program into a host application's
- * main entry point.
- *
- * This module is the low-level layer used by platform adapters to run a main
- * effect, observe its fiber, report unhandled failures, and translate the
- * resulting `Exit` into an application or process exit code. Application code
- * usually calls the platform-provided runner; runtime integrations use
- * {@link makeRunMain} directly.
- *
- * **Mental model**
- *
- * - {@link makeRunMain} forks the supplied `Effect` and gives the host adapter
- *   the running fiber plus a teardown callback
- * - The host adapter installs platform-specific hooks such as signal handlers,
- *   fiber observers, process exits, worker termination, or test harness
- *   callbacks
- * - {@link defaultTeardown} maps successful exits to `0`, interruption-only
- *   failures to `130`, failures with {@link errorExitCode} to that code, and
- *   other failures to `1`
- * - {@link errorReported} controls automatic failure logging; set it to
- *   `false` on errors that have already been reported
- *
- * **Common tasks**
- *
- * - Build a platform runner: {@link makeRunMain}
- * - Reuse the standard exit-code rules: {@link defaultTeardown}
- * - Customize failure exit codes: {@link errorExitCode},
- *   {@link getErrorExitCode}
- * - Control automatic failure logging: {@link errorReported},
- *   {@link getErrorReported}
- *
- * **Gotchas**
- *
- * - `makeRunMain` starts the main fiber, but the adapter callback is
- *   responsible for observing that fiber and eventually invoking teardown.
- * - `disableErrorReporting` only disables automatic failure logging. It does
- *   not change the `Exit`, interruption behavior, or teardown exit-code rules.
- * - Error markers are read from `Cause.squash(cause)`, so causes with multiple
- *   failures use the squashed failure value to determine logging and exit code.
- *
- * **Example** (Creating a minimal runner)
- *
- * ```ts
- * import { Effect, Runtime } from "effect"
- *
- * const runMain = Runtime.makeRunMain(({ fiber, teardown }) => {
- *   fiber.addObserver((exit) => {
- *     teardown(exit, (code) => {
- *       console.log(`finished with exit code ${code}`)
- *     })
- *   })
- * })
- *
- * runMain(Effect.log("booted"))
- * ```
+ * Helpers for turning an `Effect` program into a host application's main entry
+ * point. This module is the low-level layer used by platform adapters to run a
+ * main effect, observe its fiber, report unhandled failures, and translate the
+ * resulting `Exit` into an application or process exit code. It provides
+ * `makeRunMain`, the default teardown behavior, and error markers for custom
+ * exit codes and already-reported failures. Application code usually calls the
+ * platform-provided runner instead of using this module directly.
  *
  * @since 4.0.0
  */

package/src/Schedule.ts

@@ -1,66 +1,10 @@
 /**
- * Declarative policies for retrying, repeating, and pacing Effect programs.
+ * Describes policies for retrying, repeating, and pacing Effect programs.
  *
- * A `Schedule<Output, Input, Error, Env>` is a stateful policy that is stepped
- * with an input value. Each step either stops the recurrence or emits an output
- * together with the delay before the next step. Schedules are values: they can
- * be transformed, combined, and passed to retry, repeat, stream, and channel
- * APIs without running anything until the surrounding Effect program runs.
- *
- * **Mental model**
- *
- * - Constructors such as {@link recurs}, {@link spaced}, {@link fixed},
- *   {@link exponential}, and {@link fibonacci} define the base cadence or
- *   stopping rule.
- * - Combinators such as {@link both}, {@link either}, and {@link andThen}
- *   combine schedules and determine both stopping behavior and output shape.
- * - Delay helpers such as {@link addDelay}, {@link modifyDelay}, and
- *   {@link jittered} adjust pacing while preserving the schedule's control
- *   flow.
- * - Metadata-aware constructors and {@link CurrentMetadata} expose attempts,
- *   elapsed time, input, output, and duration for advanced policies.
- *
- * **Common tasks**
- *
- * - Retry a failing effect with exponential backoff and a maximum retry count.
- * - Repeat a successful effect on a fixed or spaced interval.
- * - Add jitter so concurrent clients do not retry at the same instant.
- * - Transform or retain schedule outputs with {@link map},
- *   {@link collectOutputs}, and {@link take}.
- *
- * **Example** (Retrying with bounded exponential backoff)
- *
- * ```ts
- * import { Effect, Schedule } from "effect"
- *
- * let attempts = 0
- *
- * const request = Effect.sync(() => {
- *   attempts += 1
- *   return attempts
- * }).pipe(
- *   Effect.flatMap((attempt) =>
- *     attempt < 3 ? Effect.fail("temporary failure") : Effect.succeed("ok")
- *   )
- * )
- *
- * const policy = Schedule.exponential("100 millis").pipe(
- *   Schedule.jittered,
- *   Schedule.both(Schedule.recurs(5))
- * )
- *
- * const program = Effect.retry(request, policy)
- * ```
- *
- * **Gotchas**
- *
- * - A schedule is a description; delays happen only when an operation such as
- *   `Effect.retry` or `Effect.repeat` runs it.
- * - `Schedule.recurs(3)` allows three recurrences in addition to the first run
- *   performed by retry or repeat.
- * - Combining schedules changes the output type as well as the stopping rule,
- *   so check the resulting type when using {@link both}, {@link either}, or
- *   {@link andThen}.
+ * A `Schedule<Output, Input, Error, Env>` is stepped with an input value. Each
+ * step either stops or produces an output together with the delay before the
+ * next step. Schedules are used by retry, repeat, stream, and channel APIs to
+ * decide when work should continue, how long to wait, and when to stop.
  *
  * @since 2.0.0
  */

package/src/Scheduler.ts

@@ -1,22 +1,11 @@
 /**
- * The `Scheduler` module defines the runtime scheduling services used by
- * Effect fibers. A scheduler decides how runnable tasks are enqueued, when they
- * are dispatched, and whether a fiber should yield after consuming its
- * operation budget.
+ * Controls how runnable Effect fiber tasks are dispatched.
  *
- * **Common tasks**
- *
- * - Use {@link Scheduler} to provide a custom runtime scheduler
- * - Use {@link MixedScheduler} for the default priority-aware scheduler
- * - Use {@link MaxOpsBeforeYield} to tune fairness for CPU-bound fibers
- * - Use {@link PreventSchedulerYield} only when a runtime should bypass yield checks
- *
- * **Gotchas**
- *
- * - Scheduler priorities affect the order of queued runtime tasks, not the
- *   semantic result of an `Effect`
- * - Disabling scheduler yields can improve throughput for controlled workloads,
- *   but it can also let long-running fibers monopolize the JavaScript thread
+ * A scheduler decides how tasks are queued, when queued tasks run, and when a
+ * fiber should pause so other work can continue. This module includes the
+ * scheduler service reference, the default `MixedScheduler`, dispatcher types
+ * for queued tasks, and references for tuning or disabling automatic scheduler
+ * yields.
  *
  * @since 2.0.0
  */