👏

raiseNUnder have to stay as they are, because Find can't believe us about effects above being different from each other.

I wonder whether a better name for raiseNUnder would be insertAtN…it's not a very intuitive name. or raiseAtN

I like @googleson78's realization about what raiseNUnder and raiseUnderN should mean - we could pursue that in v2 in keep it for now as-is in v1. Technically it generalizes too - raiseNUnderM 😜.

guess I'm unclear about why it's called raise in the first place

I guess this is the reason 😄

I see 🙃 I would argue that the name raiseUnder suggests, purely rhetorically, that the e is raised, while it apparently is the r. Not saying that my intuition is a reference here or that I have a better solution, but the UnderN NUnder confusion suggests that there might be room for improvement 🙂

Actually, wait. We don't need this, do we? The raiseUnderN class of functions can be achieved through repeated application of raiseUnder. Same thing with repeated raise and subsume. I don't see much point in this if it doesn't also solve the raiseNUnder functions.

We can't change raiseNUnder because of how Find works, but we can actually use subsume' in same way at call sites, where top of the stack has concrete effects. So subsume' is still works as raiseNUnder generalization.

When it comes to names, I would prefer something short - that ' can be seen as placeholder for number/postfix (possibly could be replaced with _).

Oh, well that's fine then.

I'd prefer _ instead of '.

Even in case with polymorphic "tail", that typeclass duo should resolve into concrete instance - and GHC is really good at inlining instances (see Generics).

Oh, well that's fine then.

I'd prefer _ instead of '.

why? isn't _ an indicator of void?

@tek I would say that depends a lot on context - and in this context connection to void doesn't make any sense. Instead, I would say _ looks a lot like a "placeholder" for some postfix.

Can be considered ready?