I mean I get that it's most useful in effects but it has no dependencies on effects right now

Bracket always releases resources for effects. Doesn't it depend on delay or defer?

nope, the only reference to effects is the name of one of the exitcases (ExitCase.Cancel). Everything else is MonadError only afaik

But I think no data-type outside effects has an instance of bracket so idk if it makes sense to move it

I don't think it does, bracketing almost always involves IO

If you can find a good counter example where it produced no effects outside of IO we can move it

nah, I think it's fine, I was just confused when I wrote ManagedT in arrow-extras and I wanted to use ExitCase from bracket 😅 While it has no strict dependency on effects (only extends MonadError and has no other dependencies) it's probably only ever gonna get used in effects. I also can't think of a good use-case for bracket with Either or Try that can't be solved better without it

Sounds good

@Jannis https://github.com/arrow-kt/arrow/pull/1376

what is the polymorphic version of the main algebra in ManagedT?

is this something we are missing in Bracket?

since this is implemented in terms of bracket I think we can generalize it's algebra so this is more than just a concrete data type

I understood ManagedT as a helper of sorts to ease acquisition of multiple resources that guarantees freeing in correct order. You can do the same with bracket up to some limit. ManagedT makes patterns like

List<Resource>.traverse(ManagedT.applicative()) { ManagedT({ acquire(it) }, { release(it) }) }.invoke { l: List<AcquiredResource> -> { // do useful stuff } }

possible. Also monadic acquisiton of multiple resources without deeply nesting bracket syntax is a thing. I think as soon as you need to acquire and release 2 or more resources and those depend on each other you are better of with ManagedT over Bracket, as it just composes better.

in that case how can its syntax be generalized over Bracket ?

so all bracket implementors can use this

Can't they already? Maybe I am misunderstanding that o.O

say for Example

Kleisli

which is a Reader and a concrete data type

its algebra polymorphic type class is MonadReader

which implements the algebra of

ask

, etc so other data types like Function0 etc are also capable

if ManagedT is a data type which type class can implement it's algebra flattening the monad context?

what is managedT main operation?

Also I think Resource may be a better name https://typelevel.org/cats-effect/datatypes/resource.html

It's a mix between ManagedT/Resource, I think Codensity in scalaz is the equivalent there o.O Resource is probably more descriptive. I'll think about the type-class for it, right now I think the main op is

use

but I think it's a bit weird as it is normally a one-off action. I'll play around with it for a bit and see what I can do!

if use and allocate can be implemented in Bracket there is no need for the data type as the extension functions will be projected over all instances including IO

so can that combine operator where it fusions values with the semigroup

my point is that if this just provides a nicer api for bracket case and bracket we can add it to bracket

so all of Fx auto benefits from it

Hmm right now I think there is no way to extend bracket with this functionality, mainly because bracket combines all three operations (

acquire

,

use

,

release

), but ManagedT accumulates

acquire

and

release

and then when someone is done creating resources provides

use

. Thus the main op is, contrary to what I first thought,

invoke

(or create or whatever, constructing the resource). 🤔

I see

so based on the encoding this is the issue