In this episode, we discuss a programming technique which allows us to replace overlapping instances with a decision procedure implemented using type families. The result is a bit more verbose, but arguably clearer and more flexible.
Didn't understand anything about type families up until today. They're still daunting but this video is very helpful and I'll be following along on the weekend. The boilerplate is a bit painful and you do have to work quite a ways backwards to figure out what's going on: but the power is apparent. Thank you very much! :D
Can there be a variant of Flatten that flattens [[True], [False, True]] to [True, False, True] and Just (Just (Just True)) to Just True (I think it's clear enough from these examples what generalization I've got in mind)?
Certainly! We demonstrated flattening Maybe to list just as a teaching device; flattening maybes in the manner that you describe would be quite natural. You will need to introduce a second type family IsMaybe alongside IsList. Nice exercise for the reader :)
I've envisioned a universal solution whereby no IsList, IsMaybe (perhaps IsTree and other similar variants too) are needed, just one generalizing all of them (subject to some constraint, likely Functor or Applicative). Maybe quantified constraints make it possible?
@@byteeater7662 That is a lot trickier to do. You could certainly provide an instance for (m a) , and then insist that (m) must be a monad (so that we can call join :: m (m (a) - > m a), but now you are ruling out any instances of the same shape (f a) -- unless you use overlapping instances again.
