Functions as instances of typeclasses?

Question

{-# LANGUAGE LambdaCase #-}

I have a bunch of functions which encode failure in various ways. For example:

f :: A -> Bool returns False on failure
g :: B -> Maybe B' returns Nothing on failure
h :: C -> Either Error C' returns Left ... on failure

I want to chain these operations in the same way as the Maybe monad, so the chaining function needs to know whether each function failed before proceeding to the next one. For this I wrote this class:

class Fail a where
  isFail :: a -> Bool
instance Fail () where
  isFail () = False
instance Fail Bool where -- a
  isFail = not
instance Fail (Maybe a) where -- b
  isFail = not . isJust
instance Fail (Either a b) where -- c
  isFail (Left _) = True
  isFail _ = False

However, it's possible that functions that don't conform exist:

f' :: A -> Bool returns True on failure
g' :: B -> Maybe Error returns Just Error on failure (Nothing on success)
h' :: C -> Either C' Error returns Right ... on failure

These could be remedied by simply wrapping them with functions that transform them, for example:

f'' = not . f'.
g'' = (\case Nothing -> Right (); Just e -> Left e) . g'
h'' = (\case Left c -> Right c; Right e -> Left e) . h'

However, the user of the chaining function expects to be able to combine f,g,h,f',g', and h' and have them just work. He would not know that the return type of a function needs to be transformed unless he looks at the semantics of each function he's combining, and check if they match up with whatever Fail instances he has in scope. This is tedious and too subtle for the average user to even notice, especially with type inference bypassing the user having to choose the right instances.

These functions weren't created with knowledge of how they'd be used. So I could make a type data Result a b = Fail a | Success b and make wrappers around each function. For example:

fR = (\case True -> Sucess (); False -> Fail ()) . f
f'R = (\case False -> Sucess (); True -> Fail ()) . f'
gR = (\case Just a -> Sucess a; Nothing -> Fail ()) . g
g'R = (\case Nothing -> Sucess (); Just e -> Fail e) . g'
hR = (\case Left e -> Fail e; Right a -> Sucess a) . h
h'R = (\case Right e -> Fail e; Left a -> Sucess a) . h'

However, this feels dirty. What we're doing is just certifying / explaining how each of f,g,h,f',g', and h' are used in the context of the combining function. Is there are more direct way of doing this? What I want exactly is a way to say which instance of the Fail typeclass should be used for each function, i.e, (using the names given to the typeclass instances above), f → a, g → b, h → c, and f' → a', g' → b', h' → c' for the "invalid" functions, where a',b', and c' are defined as the following instances (which overlap the previous ones, so you'd need to be able to pick them by name somehow):

instance Fail Bool where -- a'
  isFail = id
instance Fail (Maybe a) where -- b'
  isFail = isJust
instance Fail (Either a b) where -- c'
  isFail (Right _) = True
  isFail _ = False

It doesn't necessarily have to by done via typeclasses though. Maybe there's some way to do this other than with typeclasses?

If you want to chain them together like in a monad (with do notation) then you'll need to convert them all to a single type that you can then make a Monad instance for. You state that you want the type system to just figure out what a function means by failure without hints or context. In theory, I could have an infinite number of functions that each return a different Integer representing failure, how is the compiler supposed to know when a specific Integer is a failure? It only has a value as context. You can't expect the compiler to write your program for you, otherwise we'd all use Agda. — bheklilr
Yeah I don't necessarily want to make this a monad, but it will be similar. I don't expect the compiler to know which integers are failure, I want to somehow indicate which integers are failure for f, and indicate a different set for f2, and so on. For example, in Python I could just make a global variable mapping functions to some equivalent of the typeclass instances. Then it would crash at runtime instead of compile time if there's no mapping from some function the user wants to use. But it would still be safer. — og_loc

leftaroundabout leftaroundabout · Accepted Answer · 2015-02-23T23:09:20

Don't do this. Haskell's static type system and referential transparency give you a tremendously useful guarantee: you can be properly sure that some particular value means the same thing¹, regardless of how it was produced. There's neither mutability to interfer with this, nor dynamic-style “runtime reinterpretation” of expressions, as you'd need for the task you seem to envision.

If those functions you have there don't adhere to such a specification accordingly, well, then this is bad. Better get rid of them (at least, hide them and only export a re-defined version with unified behaviour). Or tell the users they'll have to live with looking up the specification of each. But don't try to hack some way around this particular symptom of broken definitions.

An easy change you could apply to just “flag” the functions where failure means the opposite as it otherwise does is to have them return such a wrapped result:

newtype Anti a = Anti { profail :: a }

instance (Anti a) => Fail (Anti a) where
  isFail (Anti a) = not $ isFail a

¹_{Mind: “same thing” in a possibly very abstract sense. There's no need for Left to be universally a “fail constructor”, it's sufficient that it's clear that it's the variant constructor associated to the first type argument, which is not what the functor/monad instance operates on – from that it follows automatically that this will “mean” failure in a monadic application.
I.e., when you've chosen the right types, stuff should be unambigious pretty much automatically; obviously the opposite is true when you're just tossing around booleans, so perhaps you should get rid of those entirely...}

Functions as instances of typeclasses?

1 Answers