Monad{Throw,Catch,Mask} are always available, so impure exceptions are allowed?

[evanrelf]

I heard in this discussion that the exceptions type classes are always available, no matter what es is in Eff es.

I found this confusing, because

1. The MonadFail instance depends on a Fail effect being present in the es type-level list, and MonadFail-style failure is handled explicitly with runFail (error as value) or runFailIO (error as pure exception).
2. runPureEff exists, which takes an Eff '[] a (where you can still throwM!) and gives you an a (no error as value or pure exception).

Is making the MonadThrow error an impure exception (i.e. throw instead of throwIO) when used with runPureEff an intentional decision? Impure exceptions aren't my cup of tea, but I respect if this was an intentional design decision. I'd just appreciate a mention of the possibility for impure exceptions in the runPureEff and/or instance MonadThrow (Eff es) docs.

Or should there be a e.g. Throw effect that's required to use MonadThrow, and a runThrow interpreter that handles the error more explicitly? That would align more closely with the MonadFail implementation, and users could still opt-in to impure exceptions by either calling throw themselves, or using an alternative interpreter for this hypothetical Throw effect.

[ocharles]

We could also change runPureEff to return Either SomeException a, making it honest that exceptions could occur.

[arybczak]

There were already discussions about this in #76 and #65, have a look to see the reasoning for this design.

[evanrelf]

Ah my bad. Thanks, I'll take a look.