[Haskell-cafe] Yet Another Forkable Class

[Nicolas Trangez]

On Fri, 2013-08-23 at 08:06 +0000, oleg at okmij.org wrote:
> > It will
> > arbitrarily pick the first match in the former and fail to compile
> in
> > the latter case.
> Of course we can have duplicate layers. In that case, the dynamically
> closest
> handler wins -- which sounds about right (think of reset in delimited
> control).

Did anyone ever consider using type-level literals (strings) to 'name'
effects (or transformer layers when using monad stacks)?

A stupid example (OTOH) could be

    updateStats :: (Member (State "min" Int) r, Member (State "max" Int)
r) => Int -> Eff r ()
    updateStats i = do
        min <- askMin
        max <- askMax
        when (i < min) $ putMin i
        when (i > max) $ putMax i
      where
        askMin :: Member (State "min" Int) r => Eff r Int
        askMin = ask
        putMax :: Member (State "max" Int) r => Int -> Eff r ()
        putMax = put
        -- askMax, putMin accordingly

Using constraint synonyms/ConstraintKinds (e.g. type StateMax r = Member
(State "max" Int) r) might reduce some notation overhead.

Just a thought.

Nicolas