search

ekmett / kan-extensions

Kan extensions, Kan lifts, the Yoneda lemma, and (co)monads generated by a functor
Other
78 stars 33 forks source link

Codensity: Add exception handling helpers #51

Closed esoeylemez closed 6 years ago

esoeylemez commented 6 years ago

Tested with:

ekmett commented 6 years ago

I'm not really against adding something like this, but it is a big merge with a rather alien API compared to what is here. It might be best to package this up as a kan-exceptions package.

esoeylemez commented 6 years ago

Would you be open to merging up to 4bb5cbf? I can then package the other module as a separate package. This is not strictly about exceptions BTW, I just wanted to avoid introducing new dependencies (like async).

Out of curiosity: do you find the API design alien or just the special-purpose nature of the new module?

ekmett commented 6 years ago

Sure, I can easily merge that part.

As for your question:

Part of it is the cWhatever convention. I try hard to avoid this sort of built-in namespacing and arbitrary abbreviation.

The other part is that this library mostly provides stuff implied by the mathematics, as a tool useful for folks to learn a bit of category theory or transform their code to get better asymptotics.

Adding a large API full of incidental complexity seems to make it harder for the library to perform these central functions.

Finally, there is the question of whether or not it is a good idea to do lots of exception-based cleanup in a CPS'd library as there become a mess of fiddly issues with masking exceptions, which I suspect will lead to a lot of churn in patches and issues on code I didn't write and haven't fully digested. CPSed code and asynchronous exceptions lead to a good deal of pain as there are, ultimately issues around ensuring the linearity of continuation reuse.

esoeylemez commented 6 years ago

Yeah, I understand. Thanks for elaborating. I have just rebased and reduced my PR for your convenience.

I'm going to turn this into a separate package. As for your concerns about CPSed exception handling it's actually not that complicated, but it does need to be explained, so I might write an article about it or perhaps even just include it in the module documentation.

BTW, in the spirit of avoiding built-in namespacing I would very much prefer to write C.lower over lowerCodensity. =P

ekmett commented 6 years ago

Usually, I'd just call the operation lower, but given that the operation for comonad transformers is lower and this isn't part of that class, I decided to name the special case explicitly to avoid folks importing the module qualified.