About the monads in ScottyT and ActionT

[echaozh]

ScottyT and ActionT share the same monad as their type parameters. From the code, I see that ScottyState needs the monad to be used in the routes, as they're constructed from ActionT. However, the monad wrapped by the ScottyT does not need to be the same monad. It's only used at initialization, and have nothing to do with ActionT. Can ScottyT be modified to use too different monads, 1 for routes, and 1 for initialization? Or perhaps dropping the second monad altogether and fix it as Identity? It looks like it cannot do much at initialization, and one can always initialize before calling scottyT.

Also, why not allow Scotty specific middlewares around actions and inside WAI ones? Say if I want to parse the cookies in the request before every action, and store the results in the monad to be used in each ActionT, there is no convenient way to do that with WAI middlewares.

[Shimuuar]

It would be possible to change ScottyT to following. It makes type somewhat more complicated but makes functions for runnning ScottyT simpler (no ∀a. m a → n a parameter).

data ScottyT e m n a = ScottyT (StateT (ScottyState e m) n a)

scottyAppT :: (Monad m, Monad n)
           => (m Response -> IO Response)
           -> ScottyT e m n ()
           -> n Application

I'm not sure about advantages of this approach but it does make sense.

[ehamberg]

I'm also wondering about this. I'm experimenting with building a library on top of scotty and this design choice makes that diffidult. I would like to use my own, custom monad stack for ScottyT, but would like to let users supply their own handlers for routes, since ActionT would then need the same custom monad. I'm not very familiar with Scotty's code, but is there a good reason for this being the case? Would it be hard to change? :)