Need ProgramT constructors to write other lifting instances about operational HOT 9 CLOSED

Actually, it should always be possible to write the necessary instances using the viewT function. This is the appropriate destructor for ProgramT. The MonadReader instance in the source code uses the constructors only because it is convenient, not because it is necessary.

I'm not familiar with Control.Lens.Zoom. Could you elaborate on the particular class that you want to implement?

from operational.

@HeinrichApfelmus I just spent a while trying to write local (from MonadReader) using viewT instead of pattern matching, and it doesn't seem possible to me. Can you show me how this can be done? Because if it is possible, then the Zoom instance is certainly doable as well. I just can't see what the technique for doing this is.

from operational.

@andrewthad

I do not test the code below, but I believe this should do the trick:

EDIT: Updated this version to work correctly. See below for a shorter variant.

{-# LANGAUAGE RankNTypes, ScopedTypeVariables #-}
import Control.Monad
import Control.Monad.Operational
import Control.Monad.Trans

instance MonadReader r m => MonadReader r (ProgramT instr m) where
    ask   = lift ask
    local = liftLocal local

liftLocal :: forall m instr b r. Monad m => (forall a. r -> m a -> m a)
    -> (r -> ProgramT instr m b -> ProgramT instr m b)
liftLocal local r m = eval =<< lift (local r (viewT m))
    where
    eval :: Monad m => ProgramViewT instr m c -> ProgramT instr m c
    eval (Return x)     = return x
    eval (instr :>>= k) = singleton instr >>= liftLocal local r . k

It's really just another way of writing the code that used constructors. Note that the return type of viewT being in the Monad m corresponds to the case where we handle the Lift constructor.

from operational.

I've created a branch that attempts to use the alternative MonadReader instance you have provided: andrewthad@80f23e9

It fails to compile with the following error:

/home/andrew/Development/operational/src/Control/Monad/Operational.hs:315:32:
Couldn't match type ‘m’ with ‘ProgramT instr m’
  ‘m’ is a rigid type variable bound by
      the type signature for
        liftLocal :: Monad m =>
                     (forall a. r -> m a -> m a)
                     -> r -> ProgramT instr m b -> ProgramT instr m b
      at src/Control/Monad/Operational.hs:313:21
Expected type: ProgramT instr m (ProgramViewT instr m b)
  Actual type: m (ProgramViewT instr m b)

I don't think that this issue can be worked around. The problem is that viewT wraps the result in the the ProgramT's inner monad m, and you can't get rid of the m. My issue about mapProgramT illustrates a similar situation in which a function that modifies a ProgramT cannot be written without access to the data constructors.

from operational.

This works for me:

local r p = do
    v <- lift $ viewT p
    case v of
        Return a -> return a
        i :>>= k -> singleton i >>= local r . k

from operational.

@emilaxelsson You are right. Thanks for coming up with the solution.

I guess the only remaining question is how the runtime efficiency of the two approaches differs. I don't know how a pattern match with viewT compares to a real pattern match on a program. I'll try to benchmark these two approaches as some point to see if viewT incurs a considerable slowdown or not. If it does, then it seems like exporting the data constructors would be helpful for people who want to really optimize a certain function.

from operational.

@emilaxelsson Thanks! Note that this should actually be

local r p = do
    v <- lift $ local r (viewT p)
    case v of
        Return a -> return a
        i :>>= k -> singleton i >>= local r . k

You need to include a call to local for the base monad, otherwise the function will just be the identity function.

from operational.

Ah, yes indeed! (It wasn't quite the identity function because of the call to local on k, but still wrong.)

from operational.

I'm now very skeptical that you can even do this directly, with or without the constructor, so I'm just going to close the issue based on the discussion.

from operational.