[Haskell-cafe] extensible effects and open unions

[oleg at okmij.org]

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!