The EnvFx data type will actually bundle this functionality and the actual polymorphic syntax for this is that this available for all MonadReader instances for which F provides a Bracket instance

EnvFx will become EnvIO

R

here in managed T is nothing but R in the Reader, that is anything from the environment

operator fun <A> invoke(use: (R) -> Kind<F, A>): Kind<F, A>

is the same as

effect

for

EnvFx

which is

suspend (R) -> Either<E, A>

I think ManagedT as a type class is still useful

but it should extend MonadReader and require a bracket instance

Hmm I think MonadReader and ManagedT are quite diffrent

and live in the MTL module

how are they different?

oh and yes it should be in mtl

that looks to me like a type class more than a data type

a type class which depends on the bracket instance of F

MonadReader provides access to some env, but does not care about how this env gets created or released at all, ManagedT deals with creation and releasing of resources and only then provides it. The last step, the function invoke, is similar. But ManagedT is about the steps before

that is why MonadReader is weaker and this should extend it

ask

already gives you

R

I guess the question is... Is

ManagedT

a

MonadReader

that given a

Bracket instance

can guarantee resource represented by

R

release etc?

Yeah I can't really think of a MonadReader instance for ManagedT, as its not about providing, but about creation of R

I see

I think

R

as a typeparameter-name makes this quite confusing 😄

I just noticed

R

is the computation value in map and flatMap

nevermind

it's valid and it does not need MTL it can be on effects-data

my bad, I missed that

yes this should follow

F, G, H, ... A, B, C

conventions

Yeah

R

for resource made sense at the time, but with EnvFx this will be very confusing. I'll change it. Using

ManagedT

to create an Env for EnvFx is a good use case tho 🙂

yeah totally

we should also just call this

Resource

or something better than

ManagedT

True, I went after the ticket and the linked blog, but Resource is much nicer (I don't think codensity as a name can be considered either)

hi @Adi Polak!!