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 oleg@okmij.org writes:
I must stress that OpenUnion1.hs described (briefly) in the paper is only one implementation of open unions, out of many possible. For example, I have two more implementations. A year-old version of the code implemented open unions *WITHOUT* overlapping instances or Typeable. http://okmij.org/ftp/Haskell/extensible/TList.hs
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? 2] scope for impredicative/first-class polymorphism
By polymorphic effects you must mean first-class polymorphism (because the already implemented Reader effect is polymorphic in the environment). First of all, there are workarounds.
what are the "workarounds" in question?
Second, I'm not sure what would be a good example of polymorphic effect (aside from ST-monad-like).
the paper mentioned "explicitly marking state, and providing an allocation system using monadic regions". is this related to http://okmij.org/ftp/Haskell/regions.html#light-weight and if so, what work needs to be done to apply those ideas to extensible-effects? -- Suhail