<div dir="auto"><div>Hmm... that implementation of `pass` isn't quite right for lazy WriterT. I guess it needs to be</div><div dir="auto"><br></div><div dir="auto"><div dir="auto" style="font-family:sans-serif">pass m = do</div><div dir="auto" style="font-family:sans-serif"> ~(a, f) <- m</div><div dir="auto" style="font-family:sans-serif"> edit f</div><div dir="auto" style="font-family:sans-serif"> pure a</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019, 11:46 AM David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.</div><div dir="auto"><br></div><div dir="auto">`pass` is a rather surprising piece of the API that definitely seems to want its own subclass. Another way to express its idea is</div><div dir="auto"><br></div><div dir="auto"> edit :: (w -> w) -> WriterT w m ()</div><div dir="auto"><br></div><div dir="auto">This is equally powerful:</div><div dir="auto"><br></div><div dir="auto"> edit f = pass $ pure ((), f)</div><div dir="auto"> pass m = do</div><div dir="auto"> (a, f) <- m</div><div dir="auto"> edit f</div><div dir="auto"> pure a</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">instance MonadWriter String IO where</div><div dir="auto"> tell = hPutStr stderr</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019, 12:49 AM Zemyla <<a href="mailto:zemyla@gmail.com" target="_blank" rel="noreferrer">zemyla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I wish we could separate listen and pass from the Writer monad, and eventually deprecate them. Doing so would solve so many problems.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2019, 23:10 David Feuer <<a href="mailto:david.feuer@gmail.com" rel="noreferrer noreferrer" target="_blank">david.feuer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 29, 2019, 11:42 PM Li-yao Xia <<a href="mailto:lysxia@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">lysxia@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks like an interesting problem, but I'm a little confused about <br>
the objective. In what sense is it "faithful"?<br>
<br>
> to prevent the computation from gaining unauthorized access to the state.<br>
<br>
Does that property have a formal definition? Are we looking for a <br>
one-to-one correspondence between a "better" WriterT and the naive WriterT?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Exactly. They should be isomorphic as sets and "morally" isomorphic as monads. There will of course be distinctions in strictness </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What about (w -> s -> s) instead of ((w -> w) -> (s -> s))? It seems <br>
that `pass` needs the (w -> w), but if we leave `pass` aside, does that <br>
still look about right?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. That's the type I started with, and then I got to `pass` and realized it just wouldn't do the trick.</div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
</blockquote></div></div></div>
</blockquote></div></div></div>