Add 'Raise' and 'Subsume'

[TheMatten]

See https://funprog.srid.ca/polysemy/raiseunder-and-multiple-effect-interpretation.html and #369.

[tek]

👏

[TheMatten]

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

[tek]

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

[TheMatten]

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 😜.

[tek]

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

[TheMatten]

I guess this is the reason 😄

[tek]

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 🙂

[KingoftheHomeless]

Like magic!

I don't like the names. Something like raiseGeneral and subsumeGeneral would be better.

I'm also slightly concerned about the performance characteristics, but if they turn out to be bad, we can revert the definitions of raiseUnder and subsume and friends to their earlier definitions at a later points.

[KingoftheHomeless]

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.

[TheMatten]

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 _).

[KingoftheHomeless]

Oh, well that's fine then.

I'd prefer _ instead of '.

[googleson78]

I was also thinking whether the typeclasses would be an issue, but I'm hoping that if you use the concrete versions there won't be any (additional) dictionary passing?

[TheMatten]

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

[tek]

Oh, well that's fine then.

I'd prefer _ instead of '.

why? isn't _ an indicator of void?

[TheMatten]

@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.

[TheMatten]

Can be considered ready?

[KingoftheHomeless]

I consider it so.

Regarding _ vs ': ''s also got a convention, namely, strictness. Neither convention is universally observed: for example, mask_ isn't a void-ed version of mask.