Discussion: add more idiomatic versions of catchJust and/or handleJust

Ben Millwood haskell at benmachine.co.uk
Thu Jul 14 15:56:22 UTC 2016


Am I right in thinking that `catch` is equivalent to
`catchJust fromException`? Perhaps the intention is that if you have an 
implementation of `fromException` but haven't defined an instance of 
`Exception` for whatever reason, you can use `catchJust` directly? Or if 
you have a slight variant of `fromException` that isn't quite worth its 
own typeclass instance? Analogously to `sortBy` vs. `sort`, for example.

I have no particular vote on the proposal and do not intend the above as 
a defence of `catchJust`, just a possible perspective on it.

On Wed, Jul 13, 2016 at 02:23:04PM -0700, Theodore Lief Gannon wrote:
>+1 on catchMaybe from this corner of the peanut gallery, FWIW. It feels far
>more idiomatic, and provides the same power with fewer moving parts.
>On Jul 13, 2016 1:14 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> 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 <andreas.abel at ifi.lmu.de>
>> wrote:
>> > 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 at 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 at gu.se
>> > http://www2.tcs.ifi.lmu.de/~abel/
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>

>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



More information about the Libraries mailing list