I hate having to make arbitrary choices when writing code. With
`catchJust`, I have to decide what to calculate in the selector and
what to calculate in the handler. As far as I can tell, there's never
any reason to leave any calculation for the handler.
I don't think the `Maybe (IO a)` type is nearly as hard to think about
as exceptions themselves are. The handler either provides a recovery
action or it doesn't. The catchMaybe signature strikes me, personally,
as easier to understand, because I don't need to use parametricity to
string the pieces together.
On Wed, Jul 13, 2016 at 3:36 PM, Andreas Abel
I can only guess why catchJust was designed like it is. A type like
b -> Maybe (IO a)
is not as intuitive as the types
e -> Maybe b -- ^ if you do not understand this, get back to Haskell school!
b -> IO a -- ^ a continuation, we know this from >>= and friends
A type like Maybe (IO a) is more unusual, requires more thinking.
+-0. I have no opinion on what is better.
On 12.07.2016 02:23, David Feuer wrote:
The catchJust and handleJust functions seem a bit weird and unidiomatic.
catchJust :: Exception e => (e -> Maybe b) -- ^ Predicate to select exceptions -> IO a -- ^ Computation to run -> (b -> IO a) -- ^ Handler -> IO a catchJust p a handler = catch a handler' where handler' e = case p e of Nothing -> throwIO e Just b -> handler b
This takes two functions and then puts them together. I would think the more natural API would be
catchMaybe :: Exception e => IO a -> (e -> Maybe (IO a)) -> IO a catchMaybe m handler = catch m handler' where handler' e = fromMaybe (throwIO e) (handler e)
This is exactly as powerful as catchJust:
catchMaybe m handler = catchJust handler m id catchJust p m handler = catchMaybe m $ fmap handler . p
But catchMaybe doesn't enforce the arbitrary separation between "selection" and "handling".
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- Andreas Abel <>< Du bist der geliebte Mensch.
Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden
andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/