I would definitely like to see `listen` split out, since it adds a sort of introspection that can't be good for CPS-based implementations.

`pass` is a rather surprising piece of the API that definitely seems to want its own subclass. Another way to express its idea is

    edit :: (w -> w) -> WriterT w m ()

This is equally powerful:

    edit f = pass $ pure ((), f)
    pass m = do
      (a, f) <- m
      edit f
      pure a

The essence of edit/pass is that it adds the ability to make arbitrary modifications to the "log". That excludes instances for which the log itself is not accessible at all.

instance MonadWriter String IO where
  tell = hPutStr stderr

On Fri, Aug 30, 2019, 12:49 AM Zemyla <zemyla@gmail.com> wrote:
I wish we could separate listen and pass from the Writer monad, and eventually deprecate them. Doing so would solve so many problems.

On Thu, Aug 29, 2019, 23:10 David Feuer <david.feuer@gmail.com> wrote:
On Thu, Aug 29, 2019, 11:42 PM Li-yao Xia <lysxia@gmail.com> wrote:
This looks like an interesting problem, but I'm a little confused about
the objective. In what sense is it "faithful"?

 > to prevent the computation from gaining unauthorized access to the state.

Does that property have a formal definition? Are we looking for a
one-to-one correspondence between a "better" WriterT and the naive WriterT?

Exactly. They should be isomorphic as sets and "morally" isomorphic as monads. There will of course be distinctions in strictness 


What about (w -> s -> s) instead of ((w -> w) -> (s -> s))? It seems
that `pass` needs the (w -> w), but if we leave `pass` aside, does that
still look about right?

Yes. That's the type I started with, and then I got to `pass` and realized it just wouldn't do the trick.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.