oleg-py / meow-mtl Goto Github PK

There are cases when I'd like to be able to manually instantiate RefMonadState, would you consider lifting the private on the CatsEffectMtlInstances object ?

given type HasNetworkConfig[R] = MkLensToType[R, NetworkConfig]

HasNetworkConfig[AppConfig] could summon an instance from the implicit scope.

Hey Oleg,

I'm confused about your usage of the term mtl in this library name (compared to https://wiki.haskell.org/Monad_Transformer_Library) as I don't really see anything about "transformer" in there?

Am I missing something? What is the motivation for the naming?

Thanks!

Hello,

Just wondering if there's a plan to add support for 2.13.

Thanks.

TaskLocal is pretty cool and should allow us to get an instance of ApplicativeLocal, which abstracts over ReaderT.

To be done:

• Wait for Monix 3.0.0-RC2 release
• Create a separate module for the project
• Implement :)

Hello!

Would it be possible to somehow support fs2 with deriving prisms?

I have setup my project to handle custom business errors, and it works great if I for example do Sync[F].raiseError(CustomException("test")

But does not work when doing Stream.raiseError(CustomException("test")).

The stack trace says something of the lines of CustomException: null.

I was wondering what'd happen if I asked meow to generate instances/lenses for a type with same-type fields:

case class Foo(s: String, y: String)

import com.olegpy.meow.optics.MkLensToType

implicitly[MkLensToType[Foo, String]]

Current behavior: the generated lens directs to the s field.
Expected behavior: compilation error. The target type is ambiguous and could match either of the class's fields (let alone if any of them was nested), and the current behavior isn't really what a user would expect.

Do you think meow-mtl should make it harder to derive such lenses? If someone really wants to target a field that can't be uniquely determined by its type, maybe force them to pass a symbol with the field's name, or provide the lens themselves?

I was trying out the library, it's pretty cool.

this example from the docs does not compile, because of the constraint that F[_] has to be an abstract type

Could you explain the reason for the existence of such a constraint ?

package sandbox

import cats._
import cats.data._
import cats.instances.list._
import cats.instances.try_._
import cats.instances.vector._
import cats.mtl._
import cats.mtl.instances.state._
import cats.syntax.functor._
import com.olegpy.meow.hierarchy._
import com.olegpy.meow.optics.MkLensToType
import shapeless.Lens

import scala.language.higherKinds
import scala.util.Try

object Sandbox extends App {
  trait World
  trait Effect
  case class Application(id: Int, name: String)
  case class Patch(field: String, value: Any)

  implicit def writerLens[T, L]: MkLensToType[Writer[L, T], T] =
    new MkLensToType(new Lens[Writer[L, T], T] {
      override def get(s: Writer[L, T]): T = s.value
      override def set(s: Writer[L, T])(a: T): Writer[L, T] = s.map(_ => a)
    })

  type Rnt[T] = RWST[Try, World, List[Effect], Writer[Vector[Patch], Application], T]

  def mod[F[_]: Functor : MonadState[?[_], Application]](f: Endo[Application]): F[Unit] = {
    MonadState[F, Application].modify(f)
  }

  deriveMonadState[Rnt, Writer[Vector[Patch], Application], Application]
}

Compiles with:

[error]  both method ambiguousIfPresent in object Refute of type [T](implicit ev: T)shapeless.Refute[T]
[error]  and method refute in object Refute of type [T](implicit dummy: DummyImplicit)shapeless.Refute[T]
[error]  match expected type com.olegpy.meow.internal.IsAbstract[sandbox.Sandbox.Rnt]
[error]   deriveMonadState[Rnt, Writer[Vector[Patch], Application], Application]

AFAIK compiler will always provide ClassTag[] for an arbitrary type, Refute will always be ambiguous in this case. Any thoughts?

Recently, I encountered this behavior:

//given
case class AppConfig(foo: FooConfig)
case class FooConfig(value: Int)

//when
implicit val readAppConfig: ApplicativeAsk[F, AppConfig] = new DefaultApplicativeAsk[F, AppConfig] {
  override val applicative: Applicative[F] = F
  override val ask: F[AppConfig] = config.pure[F]
}

//comment this line and the last line doesn't compile
implicitly[ApplicativeAsk[F, AppConfig]]

import com.olegpy.meow.hierarchy._
ApplicativeAsk[F, FooConfig]

The error I'd get if not for the implicitly[ line:

diverging implicit expansion for type cats.mtl.ApplicativeAsk[F,FooConfig]
[error] starting with method deriveApplicativeAsk in trait Priority2
[error] ApplicativeAsk[F, FooConfig]

I don't have any cats-mtl imports (apart from the type names ApplicativeAsk/DefaultApplicativeAsk). It appears like the compile isn't able to use the correct derivation method unless there's a hint from the user (being the implicitly[] call.

I'm using Scala 2.12.7 and meow-mtl 0.2.0. Do you think it's a compiler bug or something related to meow itself?

It can be convenient to allow a MonadState[F, S] to serve as an ApplicativeAsk[F, S]. We can think of the former constraint as the ability to read and update system state, and the latter as simply the ability to read it. If all we need is to read the state, the least privilege principle suggests that a ApplicativeAsk[F, S] constraint is preferable.

Traditionally, Reader monad is associated with reading outside configuration. However, IME it also works well to read the domain model of a stateful application (or some part thereof, eg by the lensing techniques already available in this library).

An example of value can be found in the meow-mtl readme use case

This is a proposal to consider an opt-in extra derivation that provides a ApplicativeAsk[F, S] should a MonadState[F, S] instance be available.