Hi Suhail,
On Fri, Nov 28, 2014 at 4:52 AM, Suhail Shergill
having recently taken over as maintainer for the extensible-effects library, i'm looking to address some of the current implementation concerns. specifically:
1] the use/need for Typeable in Data.OpenUnion how does the TList.hs implementation compare with, say, OpenUnion2.hs? neither require OverlappingInstances, and the TList implementation also does away with the Typeable constraint. are there reasons why it might not make sense to use TList.hs as the only/default implementation of Data.OpenUnion?
You need to write an instance of TCode for every different "effect" included in the union for the lookup to work. Check out this example usage of TList.hs: mkV :: Int -> ([] :> Maybe :> Void) Int mkV 1 = H [1,2,3] mkV 2 = T (H (Just 5)) mkV 3 = T (T (undefined :: Void Int)) -- | >>> test1 -- [Just [1,2,3],Nothing,Nothing] test1 :: [Maybe [Int]] test1 = map (prj . mkV) [1 .. 3] -- | >>> test2 -- [Nothing,Just (Just 5),Nothing] test2 :: [Maybe (Maybe Int)] test2 = map (prj . mkV) [1 .. 3] type instance TCode [] = Z type instance TCode Maybe = S Z If you instead had type instance TCode [] = Z type instance TCode Maybe = Z then test2 would not typecheck, and the type error doesn't suggest (to me) that the TCode instances are wrong. I think you're better off depending on a type family Eq :: Bool where Eq x x = True Eq x y = False Or the equivalent with overlapping instances if the code is supposed to work with ghc-7.6. Another objection about TList is that it is a linked list, so operations with types at the "end" of the union are probably relatively slow at runtime, since you end up pattern matching on "n" T constructors in some cases. It might be faster to have more of that traversal done at compile time as in: http://code.haskell.org/HList/Data/HList/Variant.hs Or with unions that use Typeable. I'm not sure about your other questions. Regards, Adam