[Haskell-cafe] best practice for lifting of IO and could lifting

[Oleg]

Roman Cheplyaka wrote:
> Not really. You are passing 'ref' into myReadFile by hand here. If you
> are willing to pass parameters by hand, there is no need in IORef at
> all; you could just as well pass header directly.

I confess in embellishing the problem and tacitly upgrading Reader to
the State. The original problem seemed too simple. In penance, I show
the solution to the original problem, using exactly the signature of
the original poster, and using exactly his code for myReadFile,
(but with the lifted type, which is what he wanted, it seems).


> data ColumnHeaders = FirstLine | None
> getFileContents :: ReaderT ColumnHeaders IO String
> getFileContents = do
>   header <- ask -- can ask it here
>   lift $ withCSV "data.csv" (\handle -> runReaderT (myReadFile handle) header)
>      where


> myReadFile :: Handle -> ReaderT ColumnHeaders IO String
> myReadFile handle = do
>   header <- ask   -- Now, we can ask it, alright
>   case header of
>     None      -> return ""
>     FirstLine -> lift $ hGetLine handle -- skip first line
>   text <- lift $ hGetContents handle
>   return text

The idea is simple: since withCSV wants its callback to be IO rather
than ReaderT IO, it means the withCSV is not capable of altering the
environment of the callback. Therefore, the myReadFile is executed in
the same environment, regardless of the Handle. Once we understand
this, the solution is trivial.

So, to answer the question of the original poster: it seems we can do
what he wants withCSV he got. There is no need to ask withCSV author
for anything.


> I agree that *given a ReaderT* (or implicit params, or your implicit
> configurations), you can emulate StateT/WriterT using IORefs (but only
> one way of stacking w.r.t. exceptions).

Actually, it is easy to get other ways of `stacking with respect to
exceptions.' Once we get persistent state (which is what IORef
provide), we can always discard that state by writing an appropriate
exception handler. I guess I can make another stab at monad
transformers and say that thinking in terms of stacks is not always
productive.