On Maybe's instance, such as Instances.functor(maybe()), and then MAYBE.narrow. Any of the functor, applicative or monad lookups gives that instance. A Kind has no methods of its own, so calling map on it does not compile: javac cannot find a "method map" on it.

Kind<MaybeKind.Witness, Order> found = MAYBE.widen(Maybe.just(order));
found.map(placed -> placed.customer());

Where this lives: The five steps.

via, and no. An EitherPath holds an Either and calls it directly, with no Kind and no instance between. Monad's flatMap is the same operation over Kind, and the two give the same result.

Where this lives: Two encodings, one algebra.

Unit, whose one value is Unit.INSTANCE. Void's only value is null, and what of(null) does depends on the container: Either's throws, and Maybe's gives Nothing. Unit.INSTANCE is a value that every container holds.

Where this lives: Unit: a value for "nothing to return".

The exception the supplier threw. CompletableFuture's instance unwraps the cause from any CompletionException before it calls the handler.

Where this lives: What each instance does.

One. A token's instance implements the whole Functor, Applicative, Monad chain, so the three lookups return that same object, for Try as for Maybe.

Where this lives: Zero-argument lookups.

A Kind inside a Kind, and flatMap. map puts whatever its function returns inside the container, a container included. flatMap runs a step that gives back a container, and flattens the result into one. The compiler agrees with both types:

Kind<EitherKind.Witness<String>, Kind<EitherKind.Witness<String>, Customer>> nested =
    monad.map(findCustomer, found);
Kind<EitherKind.Witness<String>, Customer> flat = monad.flatMap(findCustomer, found);

Where this lives: What a Monad adds.

Two from Validated, and one from Either. traverse combines the results with the instance it is given, so it keeps what that instance's map2 keeps. Validated's joins the errors with its semigroup, here one that keeps them all, and Either's keeps the first.

Where this lives: What each instance does, and What builds on Applicative.

The Maybe pair is, and the Optional pair is not. A Maybe is its own Kind, so widening returns it. An Optional cannot implement Kind, so each widen wraps it in a new holder.

Where this lives: The pieces each type provides.

Four, and no. par combines with List's map2, which gives every combination. from uses List's flatMap, which runs the next step on every element, so it reaches the same four.

Where this lives: Independent steps with par, and What each instance does.

A Functor is enough, because counting needs only map:

  // Only map is needed, so the method asks for a Functor
  public static <F extends WitnessArity<TypeArity.Unary>> Kind<F, Integer> countLines(
      Functor<F> functor, Kind<F, Order> orders) {
    return functor.map(order -> order.lines().size(), orders);
  }

Where this lives: One method for any container.

An Applicative, because the two values do not depend on each other, so map2 combines them:

  // The order and the email are found apart, so the method asks for an Applicative
  public static <F extends WitnessArity<TypeArity.Unary>> Kind<F, String> receiptLine(
      Applicative<F> applicative, Kind<F, Order> order, Kind<F, EmailAddress> email) {
    return applicative.map2(order, email, (o, e) -> o.id() + " to " + e.value());
  }

With Validated's instance and a semigroup that joins lists, it gives both errors.

Where this lives: One method for any container.

A MonadError, with the service call in a handler, so it runs only when the cache missed. recoverWith would take the service's result as a value, so Java would call the service first, whatever the cache gave:

  // The service is called only when the cache missed, so the call sits in a handler
  public static <F extends WitnessArity<TypeArity.Unary>, E> Kind<F, Order> fromCacheOr(
      MonadError<F, E> monadError, Kind<F, Order> cached, Supplier<Kind<F, Order>> service) {
    return monadError.handleErrorWith(cached, missed -> service.get());
  }

Where this lives: Should you use recoverWith or handleErrorWith?