Expose more of RuntimeSplice

[hesselink]

We have a MonadReader-like typeclass that we'd like to implement for RuntimeSplice m. Currently this is not possible, since you can't implement local. One option is to expose the RuntimeSplice constructor and unRS deconstructor. Then we could do something like:

instance OurReader m => OurReader (RuntimeSplice m) where
  ourAsk = lift ourAsk
  ourLocal f = RuntimeSplice . ourLocal f . unRT 

Another option is to provide an instance of MonadTransControl for RuntimeSplice. This could be used to write ourLocal and would also allow use of the functions from lifted-base, like catch.

I could send a pull request for either option, if you let me know which (if any) you prefer.

[mightybyte]

Hmm, I'm a bit reluctant to expose the constructor. Can you tell me a little more about what your reader type class does so I can understand your use case more?

[hesselink]

It's just MonadReader by a different name, so that you can use both at the same time. Happstack does a similar thing with their ServerMonad. This way you can have two Readers in your stack, and access them without knowing how deep they are in your stack.

The issue is more general than our type class though. Any function with RuntimeSplice on a negative position is impossible to implement from outside the package. This goes for things like catch, fork, timeout.

What are your objections to exposing the constructor? Unsafety? Hiding of implementation? Many packages expose internals through a .Internal module, which the (implicit or explicit) understanding that the module is unsafe, unstable or both.

What about a MonadTransControl instance? You currently depend on MonadCatchIO, which I believe is broken for ErrorT (finally and finalizers of bracket and friends won't always be called on a Left).

[mightybyte]

Yeah, but what are you reading from? Would a passthrough Reader instance do the job for you, or are you trying to make a reader that gets its data from some Promise?

I'm reluctant to expose the constructor because I don't really want to expose the internal HeterogeneousEnvironment. An opaque RuntimeSplice monad feels like the right level of abstraction to me. A MonadTransControl instance might be ok here, I need to look into that a little more.

[mightybyte]

Regarding MonadTransControl...right now the Snap Framework is standardized on MonadCatchIO, so I'm reluctant to add monad-control at this point. However, when the new server comes out, we're switching to monad-control. So at that time I don't think I'll have any objections to a MonadTransControl instance for RuntimeSplice.

[hesselink]

Has any work been done on the switch to monad-control? I'm experimenting with something, and I need these instances for that, as well as instances for Snap. That one is tricky because of the underlying Iteratee, so if someone already figured that out, I'd appreciate it.

[mightybyte]

It's coming. @gregorycollins is working on the rewrite of snap-core [1] and snap-server [2] which uses io-streams under the hood. That will switch us to monad-control.

[1] https://github.com/snapframework/snap-core/tree/io-streams
[2] https://github.com/snapframework/new-snap-server

[hesselink]

Ah, great! Probably too soon to switch though, and it won't help me when working on the old code base.

[mightybyte]

With the 1.0 release, Heist is now using monad-control. Are you still interested in the MonadTransControl instance for RuntimeSplice?

[hesselink]

We're not using heist anymore so I don't need it at this point.