cats.mtl.Local[IO, E] from IOLocal[E] #3429

rossabaker · 2023-02-17T19:53:53Z

cats.mtl.Local's semantics are a safe and useful subset of what can be done with IOLocal. This provides easy access to a Local[F, E] instance from an IOLocal[E] value.

core takes on a cats-mtl dependency. Note that testkit already couples these release cycles.
Adds IOLocal#asLocal to get a Local view of an IOLocal value
Adds IOLocal.local to create an IOLocal and return a local view of it, inside IO.

A similar view is already in use in otel4s.

Fixes #3385.

rossabaker

Needs docs and such, but I wanted to float the interface first.

rossabaker · 2023-02-17T19:57:58Z

core/shared/src/main/scala/cats/effect/IOLocal.scala

@@ -319,4 +332,6 @@ object IOLocal {
      underlying.get.flatMap(s => underlying.reset.as(getter(s)))
  }

+  def local[E](e: E): IO[Local[IO, E]] =


otel4s has integrated LiftIO, but I'm not sure this is necessary: cats.mtl already lifts a Local[F, E] to all the common transformers over F. Everyone would pay the LiftIO tax just to cover any LiftIO instances not covered by Local.

rossabaker · 2023-02-17T19:59:57Z

core/shared/src/main/scala/cats/effect/IOLocal.scala

+      def local[B](iob: IO[B])(f: A => A): IO[B] =
+        self.modify(e => f(e) -> e).bracket(Function.const(iob))(self.set)


This could conceivably be made a method on IOLocal itself as well, with this becoming a simple delegate.

I like thin instances, but if we're discouraging non-Local use of IOLocal, maybe we shouldn't make it easier to use.

rossabaker · 2023-02-17T20:00:14Z

core/shared/src/main/scala/cats/effect/IOLocal.scala

@@ -319,4 +332,6 @@ object IOLocal {
      underlying.get.flatMap(s => underlying.reset.as(getter(s)))
  }

+  def local[E](e: E): IO[Local[IO, E]] =


I don't love the name.

armanbilge · 2023-02-17T19:58:25Z

tests/shared/src/test/scala/cats/effect/IOLocalLocalSpec.scala

+  implicit val local: Local[IO, Int] =
+    // Don't try this at home
+    unsafeRun(IOLocal.local(0)).fold(
+      throw new CancellationException("canceled"),
+      throw _,
+      _.get
+    )


We can also use syncStep here.

The left seems as messy as this, but I might be missing something.

armanbilge · 2023-02-17T20:00:37Z

core/shared/src/main/scala/cats/effect/IOLocal.scala

+  def local[E](e: E): IO[Local[IO, E]] =
+    IOLocal(e).map(_.toLocal)


I think it would be interesting to see this as a method on IO so you can do IO.local(e): IO[Local[IO, E]]. It also insulates the API from the more complex stuff going on in IOLocal—thinking from the perspective of users.

That's exactly where I wanted to put it, but it creates a cycle between IO and IOLocal that isn't already there. I don't think I mind: I can't imagine those ever not being in the same module.

They'll definitely always be in the same module. There's already an indirect cycle (through the IO case class structure and IOFiber) due to the implementation, so I don't think there's any real concern about making the ABI directly cyclic.

djspiewak · 2023-02-18T15:19:56Z

core takes on a cats-mtl dependency. Note that testkit already couples these release cycles.

This is the one thing that gives me pause. I'm concerned about it mostly because I suspect there are breaking changes we will want to make to Cats MTL in the near-ish term, which transitively breaks Cats Effect. However, as you pointed out, testkit already implies this version dependency, which is unfortunate but definitely undercuts my concern.

djspiewak · 2023-02-18T15:23:44Z

Particularly with an eye towards otel4s, are we sure we want to privilege bare IOLocal[A] in this way? My concern is that this ossifies a very particular propagation semantic rather than encouraging users to be more selective about what semantics they want.

rossabaker · 2023-02-18T15:48:34Z

I don't see that otel4s privileging bare IOLocal. It's saying context propagation should be done with cats.mtl.Local semantics, because advanced but common uses of resource and race do weird shit. I fixed the FS2 problems under stateful propagation with blunt force more than thoughtful reason, but it still wasn't satisfactory.

I do want to be cautious here, because if cats-mtl is not stable, this PR makes everything unstable. But we hope to integrate otel4s into the major networking libraries, and without cats-mtl, we're missing a typeclass and then really are privileging IOLocal.

My two questions:

If you were designing IOLocal today, what interface would you want beyond the operations of cats.mtl.Local? Remember the IOLocal can hold a Ref for cases children need to merge state back into the parent.
(Perhaps a better issue for cats-mtl) After a long period of stability, what changes do you imagine in cats-mtl? If cats-mtl-2 is coming, that changes a lot of plans for a lot of projects.

djspiewak · 2023-02-18T16:01:44Z

After a long period of stability, what changes do you imagine in cats-mtl?

I imagine very little changing in the typeclasses. I'm mostly interested in smoothing the introduction/elimination of capabilities, particularly those with lexical scopes (i.e. all the interesting ones). That's probably something that can be done in a binary-compatible fashion, but I don't know for sure until I really go deep on it.

rossabaker · 2023-02-18T16:37:01Z

otel4s could kick this can down the road by not depending on cats-mtl, restricting itself to IOLocal operations representing local semantics, and either removing support or massively duplicating code for Kleisli and all transformers. natchez-core is an approximation of what that road looks like, and it would be nice not to repeat that aspect of it.

When you say "ossifies a very particular propagation semantic," otel4s is pretty much going to have to do so with respect to tracing. We can have a tracer that uses local semantics, which sucks for spanning Resource#use and is good for everything else. Or we can span with a Resource, which gives a lovely API as long everybody uses the orthodox resource interpreter, but corrupts when they don't. Perhaps there's something behind door number three, but even then, we'll need http4s and skunk and friends to pick the same door.

rossabaker · 2023-02-19T01:38:07Z

Note that there is also lawful Stateful instance, which does weird shit with concurrency between .set and .get. Since it's lawful, it's not better nor worse than public .set. It's milquetoast to neither provide that instance nor push for deprecation of IOLocal's stateful bits, but here I sit... for now. I would love to see a practical example that can best be done as a Stateful view of IOLocal.

kubukoz · 2024-09-11T01:08:33Z

Note that there is also lawful Stateful instance, which does weird shit with concurrency between .set and .get.

I'm not sure I get the problem - one fiber's view of an IOLocal can't be changed by someone else between set and get, can it? We don't propagate updates from child fibers to the parent nor from the parent to the children, afaik, so each fiber (a unit of concurrent execution) would be immune to weird shit from others... unless you meant something else.

djspiewak · 2024-11-21T19:41:41Z

Can we get a non-draft version of this?

cats.mtl.Local[IO, E] from IOLocal[E]

f33c083

rossabaker force-pushed the mtl branch from 4e4f458 to f33c083 Compare February 17, 2023 19:55

rossabaker commented Feb 17, 2023

View reviewed changes

armanbilge reviewed Feb 17, 2023

View reviewed changes

armanbilge added this to the v3.6.0 milestone Feb 17, 2023

rossabaker added 2 commits February 17, 2023 16:21

Move IOLocal.local to IO.local

0fb5754

Scala 3 wants explicitly typed implicits

efc096d

rossabaker mentioned this pull request Feb 20, 2023

Add some helpers for using Kleisli or IOLocal for logging context typelevel/log4cats#676

Open

armanbilge mentioned this pull request Aug 15, 2023

Rebranding Cats MTL to emphasize the Capabilities, not the Monad Transformers typelevel/cats-mtl#516

Open

zarthross approved these changes Aug 15, 2024

View reviewed changes

kubukoz approved these changes Sep 11, 2024

View reviewed changes

kubukoz mentioned this pull request Sep 11, 2024

Add a variant of Trace.ioTrace that takes an existing IOLocal typelevel/natchez#1061

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cats.mtl.Local[IO, E] from IOLocal[E] #3429

cats.mtl.Local[IO, E] from IOLocal[E] #3429

rossabaker commented Feb 17, 2023

rossabaker left a comment

rossabaker Feb 17, 2023

rossabaker Feb 17, 2023

rossabaker Feb 17, 2023

rossabaker Feb 17, 2023

armanbilge Feb 17, 2023

rossabaker Feb 17, 2023

armanbilge Feb 17, 2023

rossabaker Feb 17, 2023 •

edited

Loading

djspiewak Feb 18, 2023

djspiewak commented Feb 18, 2023

djspiewak commented Feb 18, 2023

rossabaker commented Feb 18, 2023

djspiewak commented Feb 18, 2023

rossabaker commented Feb 18, 2023

rossabaker commented Feb 19, 2023

kubukoz commented Sep 11, 2024

djspiewak commented Nov 21, 2024

		def local[B](iob: IO[B])(f: A => A): IO[B] =
		self.modify(e => f(e) -> e).bracket(Function.const(iob))(self.set)

		def local[E](e: E): IO[Local[IO, E]] =
		IOLocal(e).map(_.toLocal)

cats.mtl.Local[IO, E] from IOLocal[E] #3429

Are you sure you want to change the base?

cats.mtl.Local[IO, E] from IOLocal[E] #3429

Conversation

rossabaker commented Feb 17, 2023

rossabaker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rossabaker Feb 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djspiewak commented Feb 18, 2023

djspiewak commented Feb 18, 2023

rossabaker commented Feb 18, 2023

djspiewak commented Feb 18, 2023

rossabaker commented Feb 18, 2023

rossabaker commented Feb 19, 2023

kubukoz commented Sep 11, 2024

djspiewak commented Nov 21, 2024

rossabaker Feb 17, 2023 •

edited

Loading