main branch: more fixes after upgrading to latest effect

pages/docs/coming-from-zio.mdx

@@ -44,4 +44,4 @@ In Effect, there are no predefined type aliases such as `UIO`, `URIO`, `RIO`, `T
 
 The reason for this is that type aliases are lost as soon as you compose them, which renders them somewhat useless unless you maintain **multiple** signatures for **every** function. In Effect, we have chosen not to go down this path. Instead, we utilize the `never` type to indicate unused types.
 
-It's worth mentioning that the perception of type aliases being quicker to understand is often just an illusion. In Effect, the explicit notation `Effect<never, never, A>` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO<R, A>`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging.
+It's worth mentioning that the perception of type aliases being quicker to understand is often just an illusion. In Effect, the explicit notation `Effect<A>` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO<R, A>`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging.

pages/docs/concurrency/deferred.mdx

@@ -1,6 +1,6 @@
 # Deferred
 
-A `Deferred<E, A>` is a special subtype of `Effect` that acts as a variable, but with some unique characteristics. It can only be set once, making it a powerful synchronization tool for managing asynchronous operations.
+A `Deferred<A, E>` is a special subtype of `Effect` that acts as a variable, but with some unique characteristics. It can only be set once, making it a powerful synchronization tool for managing asynchronous operations.
 
 A `Deferred` is essentially a synchronization primitive that represents a value that may not be available immediately. When you create a `Deferred`, it starts with an empty value. Later on, you can complete it exactly once with either a success value (`A`) or a failure value (`E`). Once completed, a `Deferred` can never be modified or emptied again.
 
@@ -24,7 +24,7 @@ A `Deferred` in Effect is conceptually similar to JavaScript's `Promise`. The ke
 
 ### Creating
 
-You can create a `Deferred` using `Deferred.make<E, A>(){:ts}`. This returns an `Effect<never, never, Deferred<E, A>>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`.
+You can create a `Deferred` using `Deferred.make<A, E>(){:ts}`. This returns an `Effect<never, never, Deferred<A, E>>`, which describes the creation of a `Deferred`. Note that `Deferred`s can only be created within an `Effect` because creating them involves effectful memory allocation, which must be managed safely within an `Effect`.
 
 ### Awaiting
 
@@ -36,14 +36,14 @@ To retrieve a value from a `Deferred`, you can use `Deferred.await`. This operat
 
 ### Completing
 
-You can complete a `Deferred`[E, A] in different ways:
+You can complete a `Deferred<A, E>` in different ways:
 
 There are several ways to complete a `Deferred`:
 
 - `Deferred.succeed`: Completes the `Deferred` successfully with a value of type `A`.
 - `Deferred.done`: Completes the `Deferred` with an `Exit<A, E>` type.
-- `Deferred.complete`: Completes the `Deferred` with the result of an effect `Effect<never, E, A>`.
-- `Deferred.completeWith`: Completes the `Deferred` with an effect `Effect<never, E, A>`. This effect will be executed by each waiting fiber, so use it carefully.
+- `Deferred.complete`: Completes the `Deferred` with the result of an effect `Effect<A, E>`.
+- `Deferred.completeWith`: Completes the `Deferred` with an effect `Effect<A, E>`. This effect will be executed by each waiting fiber, so use it carefully.
 - `Deferred.fail`: Fails the `Deferred` with an error of type `E`.
 - `Deferred.die`: Defects the `Deferred` with a user-defined error.
 - `Deferred.failCause`: Fails or defects the `Deferred` with a `Cause<E>`.
@@ -67,7 +67,7 @@ Here's an example demonstrating the state change of a `Deferred`:
 
 Sometimes, you may want to check whether a `Deferred` has been completed without causing the fiber to suspend. To achieve this, you can use the `Deferred.poll` method. Here's how it works:
 
-- `Deferred.poll` returns an `Option<Effect<never, E, A>>`.
+- `Deferred.poll` returns an `Option<Effect<A, E>>`.
   - If the `Deferred` is not yet completed, it returns `None`.
   - If the `Deferred` is completed, it returns `Some`, which contains the result or error.
 

pages/docs/context-management/layers.mdx

@@ -48,7 +48,7 @@ Layers are a way of separating implementation details from the service itself.
   service level.
 </Idea>
 
-A `Layer<RIn, E, ROut>` represents a blueprint for constructing a `Context<ROut>`. It takes a value of type `RIn` as input and may potentially produce an error of type `E` during the construction process.
+A `Layer<ROut, E, RIn>` represents a blueprint for constructing a `Context<ROut>`. It takes a value of type `RIn` as input and may potentially produce an error of type `E` during the construction process.
 
 In our case, the `ROut` type represents the service we want to construct, while `RIn` represents the dependencies required for construction.
 
@@ -93,9 +93,9 @@ And because the service has no dependencies, we can create the layer directly us
 
 Looking at the type of `MeasuringCupLive` we can observe:
 
-- `RIn` is `never`, indicating that the layer has no dependencies
-- `E` is `never`, indicating that layer construction cannot fail
 - `ROut` is `MeasuringCup`, indicating that constructing the layer will produce a `MeasuringCup` service
+- `E` is `never`, indicating that layer construction cannot fail
+- `RIn` is `never`, indicating that the layer has no dependencies
 
 <Info>
   Note that, to construct `MeasuringCupLive`, we used the `MeasuringCup.of`

pages/docs/context-management/services.mdx

@@ -46,7 +46,7 @@ Map<Tag, ServiceImpl>
 
 Here, the Tag acts like the "key" to the service implementation within the context.
 
-Additionally, you need to specify an identifier (in this case, the string "Random") to make the `Tag` global. This means that two tags with the same `key` must refer to the same instance.
+Additionally, you need to specify an identifier (in this case, the string "Random") to make the `Tag` global. This means that two tags with the same identifier must refer to the same instance.
 
 This feature comes in handy in scenarios where live reloads can occur, and you want to preserve the instance across reloads.
 It ensures that there is no duplication of instances (although it should not happen in the first place, some bundlers and frameworks can behave strangely, and we don't have control over them).

pages/docs/data-types/data.mdx

@@ -50,7 +50,7 @@ Let's start by creating a case class using `Case` and `case`. This combination a
 
 ```
 
-Here, we define a `Person` data type by extending `Data.Case`. We then create a constructor for `Person` using `Data.case`.
+Here, we define a `Person` data type, we then create a constructor for `Person` using `Data.case`.
 The resulting `Person` instances come with built-in equality checks thanks to the Data module, making it simple to compare them using `Equal.equals`.
 
 If you prefer working with classes instead of plain objects, you can explore the use of [`Data.Class`](#class).

pages/docs/data-types/either.mdx

@@ -87,7 +87,7 @@ The `Either` type is a subtype of the `Effect` type, which means that it can be
 In the context of `Effect`, the two members of the `Either` type are treated as follows:
 
 - `Left<E>` is equivalent to `Effect<never, E, never>`
-- `Right<A>` is equivalent to `Effect<never, never, A>`
+- `Right<A>` is equivalent to `Effect<A>`
 
 To illustrate this interoperability, let's consider the following example:
 

pages/docs/data-types/option.mdx

@@ -171,7 +171,7 @@ The `Option` type is a subtype of the `Effect` type, which means that it can be
 In the context of `Effect`, the two members of the `Option` type are treated as follows:
 
 - `None` is equivalent to `Effect<never, NoSuchElementException, never>`
-- `Some<A>` is equivalent to `Effect<never, never, A>`
+- `Some<A>` is equivalent to `Effect<A>`
 
 To illustrate this interoperability, let's consider the following example:
 

pages/docs/essentials/creating.mdx

@@ -209,18 +209,18 @@ Let's explore some common scenarios where `Effect.suspend` proves useful:
 
 The table provides a summary of the available constructors, along with their input and output types, allowing you to choose the appropriate function based on your needs.
 
-| **Function**            | **Given**                               | **To**                               |
-| ----------------------- | --------------------------------------- | ------------------------------------ |
-| `succeed`               | `A`                                     | `Effect<never, never, A>`            |
-| `fail`                  | `E`                                     | `Effect<never, E, never>`            |
-| `sync`                  | `() => A`                               | `Effect<never, never, A>`            |
-| `try`                   | `() => A`                               | `Effect<never, UnknownException, A>` |
-| `try` (overload)        | `() => A`, `unknown => E`               | `Effect<never, E, A>`                |
-| `promise`               | `() => Promise<A>`                      | `Effect<never, never, A>`            |
-| `tryPromise`            | `() => Promise<A>`                      | `Effect<never, UnknownException, A>` |
-| `tryPromise` (overload) | `() => Promise<A>`, `unknown => E`      | `Effect<never, E, A>`                |
-| `async`                 | `(Effect<never, E, A> => void) => void` | `Effect<never, E, A>`                |
-| `suspend`               | `() => Effect<A, E, R>`                 | `Effect<A, E, R>`                    |
+| **Function**            | **Given**                          | **To**                        |
+| ----------------------- | ---------------------------------- | ----------------------------- |
+| `succeed`               | `A`                                | `Effect<A>`                   |
+| `fail`                  | `E`                                | `Effect<never, E>`            |
+| `sync`                  | `() => A`                          | `Effect<A>`                   |
+| `try`                   | `() => A`                          | `Effect<A, UnknownException>` |
+| `try` (overload)        | `() => A`, `unknown => E`          | `Effect<A, E>`                |
+| `promise`               | `() => Promise<A>`                 | `Effect<A>`                   |
+| `tryPromise`            | `() => Promise<A>`                 | `Effect<A, UnknownException>` |
+| `tryPromise` (overload) | `() => Promise<A>`, `unknown => E` | `Effect<A, E>`                |
+| `async`                 | `(Effect<A, E> => void) => void`   | `Effect<A, E>`                |
+| `suspend`               | `() => Effect<A, E, R>`            | `Effect<A, E, R>`             |
 
 You can find the complete list of constructors [here](https://effect-ts.github.io/effect/effect/Effect.ts.html#constructors).
 

pages/docs/essentials/effect-type.mdx

@@ -2,15 +2,15 @@ import { Info } from "@/components/Callout"
 
 # The Effect Type
 
-The `Effect<Requirements, Error, Value>` type represents an **immutable** value that **lazily** describes a workflow or job.
+The `Effect<Value, Error, Requirements>` type represents an **immutable** value that **lazily** describes a workflow or job.
 
 It encapsulates the logic of a program that requires a collection of contextual data `Context<Requirements>` to execute.
 This program can either fail, produce an error of type `Error`, or succeed, yielding a value of type `Value`.
 
-Conceptually, you can think of `Effect<Requirements, Error, Value>` as an effectful version of the following function type:
+Conceptually, you can think of `Effect<Value, Error, Requirements>` as an effectful version of the following function type:
 
 ```ts
-type Effect<Requirements, Error, Value> = (
+type Effect<Value, Error, Requirements> = (
   context: Context<Requirements>
 ) => Error | Value
 ```
@@ -31,8 +31,9 @@ The `Effect` type has three type parameters with the following meanings:
 
 <Info>
   In the Effect ecosystem, you may often encounter the type parameters of
-  `Effect` abbreviated as `R`, `E`, and `A` respectively. This is just shorthand
-  for **R**equirements, **E**rror, and the success value of type **A**.
+  `Effect` abbreviated as `R`, `E`, and `A` respectively. This is just
+  shorthand for **R**equirements, **E**rror, and the success value of type
+  **A**.
 </Info>
 
 `Effect` values are immutable, and all Effect functions produce new `Effect` values.

pages/docs/essentials/running.mdx

@@ -16,8 +16,8 @@ If you check the console, you will see the message `"Hello, World!"` printed.
 
 <Warning>
   `runSync` will throw an error if your Effect fails or performs any
-  asynchronous tasks. In the latter case, the execution will not proceed beyond
-  that asynchronous task.
+  asynchronous tasks. In the latter case, the execution will not proceed
+  beyond that asynchronous task.
 </Warning>
 
 ```ts file=<rootDir>/src/essentials/running/runSync-throws.ts
@@ -76,11 +76,11 @@ The `runPromiseExit` function is used to execute an Effect and obtain the result
 
 The table provides a summary of the available `run*` functions, along with their input and output types, allowing you to choose the appropriate function based on your needs.
 
-| **Name**         | **Given**             | **To**                |
-| ---------------- | --------------------- | --------------------- |
-| `runSync`        | `Effect<never, E, A>` | `A`                   |
-| `runSyncExit`    | `Effect<never, E, A>` | `Exit<A, E>`          |
-| `runPromise`     | `Effect<never, E, A>` | `Promise<A>`          |
-| `runPromiseExit` | `Effect<never, E, A>` | `Promise<Exit<A, E>>` |
+| **Name**         | **Given**      | **To**                |
+| ---------------- | -------------- | --------------------- |
+| `runSync`        | `Effect<A, E>` | `A`                   |
+| `runSyncExit`    | `Effect<A, E>` | `Exit<A, E>`          |
+| `runPromise`     | `Effect<A, E>` | `Promise<A>`          |
+| `runPromiseExit` | `Effect<A, E>` | `Promise<Exit<A, E>>` |
 
 You can find the complete list of `run*` functions [here](https://effect-ts.github.io/effect/effect/Effect.ts.html#execution).

pages/docs/faq.mdx

@@ -75,7 +75,7 @@ flatMap: <A, B>(fa: Array<A>, f: (a: A) => Array<B>) => Array<B>
 
 The reason for this is that type aliases are lost as soon as you compose them, which renders them somewhat useless unless you maintain **multiple** signatures for **every** function. In Effect, we have chosen not to go down this path. Instead, we utilize the `never` type to indicate unused types.
 
-It's worth mentioning that the perception of type aliases being quicker to understand is often just an illusion. In Effect, the explicit notation `Effect<never, never, A>` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO<R, A>`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging.
+It's worth mentioning that the perception of type aliases being quicker to understand is often just an illusion. In Effect, the explicit notation `Effect<A>` clearly communicates that only type `A` is being used. On the other hand, when using a type alias like `RIO<R, A>`, questions arise about the type `E`. Is it `unknown`? `never`? Remembering such details becomes challenging.
 
 ## Layer