From 38d924e5e1044cf6f9fa9f31b3f1c9185f933ea5 Mon Sep 17 00:00:00 2001 From: Phil de Joux Date: Thu, 28 Jul 2022 13:08:01 -0400 Subject: [PATCH] Typo improvement, mis-matched parentheses. --- unliftio/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/unliftio/README.md b/unliftio/README.md index 1e88c36..e6d5971 100644 --- a/unliftio/README.md +++ b/unliftio/README.md @@ -13,7 +13,7 @@ over time. It's also very lightly tested. That said: the core concept of the code here is lightly tested, the vast majority of it is simply apply `withUnliftIO` to existing functionality. Caveat emptor and all that. -__NOTE__ The `UnliftIO.Exception` module in this library changes the semantics of asynchronous exceptions to be in the style of the `safe-exceptions` package, which is orthogonal to the "unlifting" concept. While this change is an improvment in most cases, it means that `UnliftIO.Exception` is not always a drop-in replacement for `Control.Exception` in advanced exception handling code. See [Async exception safety](#async-exception-safety) for details. +__NOTE__ The `UnliftIO.Exception` module in this library changes the semantics of asynchronous exceptions to be in the style of the `safe-exceptions` package, which is orthogonal to the "unlifting" concept. While this change is an improvement in most cases, it means that `UnliftIO.Exception` is not always a drop-in replacement for `Control.Exception` in advanced exception handling code. See [Async exception safety](#async-exception-safety) for details. ## Quickstart @@ -328,7 +328,7 @@ there are detractors of that approach: * You lose type information about which exception was thrown * There is ambiguity about _how_ the exception was returned in a - constraint like `(MonadIO m, MonadThrow m`) + constraint like `(MonadIO m, MonadThrow m)` The latter could be addressed by defining a law such as `throwM = liftIO . throwIO`. However, we've decided in this library to go the