[Haskell-cafe] Monads and scope

[Brandon Allbery]

On Mon, Nov 3, 2014 at 10:02 PM, Jeffrey Brown <jeffbrown.the at gmail.com>
wrote:

> *Question 1: Are monad stacks "transparent" -- that is, can one use a
> layer in the middle of a monad stack without thinking about other layers?*
>
> In learning about how to stack multiple monads (or more literally, how to
> stack monad transformers on top of a monad), I was expecting that in order
> to reach into the middle of the stack, one would have to stay aware of the
> order in which the stack was created, and unwrap outer transformers to get
> there.
>

If you're doing it manually, yes, that would be true. Newtype deriving can
be used to hide it, assuming that the levels are distinct enough: you can't
easily pick between two MonadReader-s, for example, without lifting past
one of them (and therefore having to at least know what order they are in).

Is that true in general? That is, if I build on top of a monad M a stack of
> monad transformers T1 T2 T3 ... TN M, and each of the Tn have different
> functions associated with them, call I call those functions without even
> remembering the order in which the transformers were stacked? Does the
> order of the stack constrain the programmer in how they chain execution
> functions like runReader, but not otherwise?
>

If you use newtype deriving, you can mostly avoid depth or ordering. One
remaining sticky case is that of `fail`; if a monad in the middle calls
`fail`, state below that monad *may* be lost. (But `fail` is rather badly
behaved in general, and is best avoided.)

Stated differently: Monadic code can call pure code. Can pure code ever
> call monadic code?
>

Something like runReaderT or runST? Or in the extreme case, unsafePerformIO
--- which is unsafe for a reason, and trying to use it to sneak into IO
from pure code will usually cause major problems, because pure code does
not expect non-deterministic results. Otherwise, the type system does its
best to avoid you unexpectedly dipping into e.g. IO from inside pure code.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20141103/caf2b43e/attachment.html>