
First of all, thank you indeed for taking over as the maintainer of the extensible-effects library. Thank you for sending me your questions directly.
1] the use/need for Typeable in Data.OpenUnion
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?
Although TList doesn't require neither overlapping instances nor Typeable, it is not so easy to use since one has to `register' any new type or effects. To show that one can indeed implement the interface of OpenUnion.hs as it is *without* Typeable or overlapping instances, I have just written http://okmij.org/ftp/Haskell/extensible/OpenUnion4.hs It is meant to be a drop-in replacement for OpenUnion2.hs. At least for my Eff code, it does indeed act that way. Nothing in the code has to be changed save for the import declaration. On the down side, in OpenUnion4.hs, projections and injections take linear time in the size of the union. How much difference it really makes in practice is unclear (since the projection and injection operations can be computed statically). Only benchmarks could tell.
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?
Well, OpenUnion4 is one workaround. Since it does not use Typeable, there are no problems with (ST s)--like types.
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?
I'm afraid that the answer is `just do it'. I thought about the implementation and jotted down some notes somewhere. There didn't seem to be any significant problems. Alas I hadn't have the time since to pursue this further. Thank you!