Very nice. The algebra here is quite small so no downside in the size of the interpreter, and ZLayer usually won't be on the hot path of most applications. Looks like a pretty good tradeoff for being able to introspect the dependency graph.

Everything is working except I don't think we can support the unwrap method with this encoding, at least if we want to retain any ability to do static analysis of what is inside the, and we have to think about the meaning of the fresh combinator.

Yes, although if you add unwrap, it could be another term: it just means in some cases (where Unwrap is used), you cannot fully analyze the layer without performing an effect.

I think we may want to consider including some type of identifier in layers.

I think you're right. Maybe something like ZIO Test:

myLayer ?? "Postgres product db"

It seems like one of the more useful things we could do here is render the dependency graph.

👍

Big 👍 on this from me. This is going to be very useful and will also allow us more power with optimization.

As for fresh, we could implement it as Fresh unary operator that triggers a rebuild of that layer; if we want to keep existing semantics. Or we can reinvestigate them.

Implemented fresh as a new instruction that says "ignore the provided memoMap when building this layer and build it with an empty one". I think this achieves nice semantics where fresh ensures a layer will be built again but if components inside the layer are themselves reused they will only be rebuilt once. For example (layer1 ++ layer1) ++ (layer1 ++ layer1).fresh should build the layer exactly twice. This also avoids having to bring in any concept of identifiers for memoization so that can be a completely orthagonal concept that is used for rendering.

@adamgfraser Superb!

@jdegoes Great! Will pursue the rendering in a follow up PR.