<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">You can even implement goto on top of Cont. See for example this: <a href="https://www.reddit.com/r/haskell/comments/1jk06q/goto_in_haskell/" class="">https://www.reddit.com/r/haskell/comments/1jk06q/goto_in_haskell/</a><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 1 Sep 2021, at 15:55, Isaac Elliott <<a href="mailto:isaace71295@gmail.com" class="">isaace71295@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">I don't have any examples. Given that Cont essentially implements unstructured control flow, I think that examples of `goto` misuse would apply by analogy.</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, <<a href="mailto:haskell-cafe@haskell.org" class="">haskell-cafe@haskell.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">I can understand the purpose if it is advising against overusing surface syntax in CPS, but here the approach is to hide continuation beneath the beloved do notation on the surface, and monad laws plus possibly further laws to be added, will make it safer to program programs by end programmers. <div class=""><br class=""></div><div class="">I do realize CPS is powerful yet dangerous (unsafe), abuse of CPS could be easy and quite unintentional, but what about abuse of "Continuation monad"?<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank" rel="noreferrer" class="">haskell-cafe@haskell.org</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class=""></div><div class="">Based on the preceding paragraph, I think that by “abuse” it means overuse, as in using CPS when you could have used straightforward code. I can imagine someone doing at the source code level the sort of things that would be done by a CPS-based compiler (converting everything possible to CPS), and ending up with a mess.</div><div class=""><br class=""></div><div class="">For example, imagine you started with this code snippet:</div><div class=""><br class=""></div><div class=""> let x = f a</div><div class=""> y = g x</div><div class=""> in h x y</div><div class=""><br class=""></div><div class="">If you fully convert that to CPS you’d end up with 3 continuations (I think) and it would be much harder to understand. And adding an additional let binding later might involve a bunch of restructuring.</div><div class=""><br class=""></div><div class="">I assume it just means that sort of thing. When someone first learns about continuations and their generality, it can be tempting to go overboard.</div><div class=""><br class=""></div><div class="">Jeff</div><div class=""><br class="">On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank" rel="noreferrer" class="">haskell-cafe@haskell.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Dear Cafe,<div class=""><br class=""></div><div class="">I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now:<br class=""><div class=""><br class=""></div><div class="">> <span style="color:rgb(232,230,227);font-family:sans-serif;font-size:13px;font-variant-ligatures:normal;background-color:rgb(24,26,27)" class="">Abuse of the Continuation monad can produce code that is impossible to understand and maintain.</span><br class=""><div class=""><br class=""></div><div class="">Which can be viewed in context of Hackage at: <a href="https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text=Abuse%20of%20the%20Continuation%20monad%20can%20produce%20code%20that%20is%20impossible%20to%20understand%20and%20maintain" target="_blank" rel="noreferrer" class="">https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text=Abuse%20of%20the%20Continuation%20monad%20can%20produce%20code%20that%20is%20impossible%20to%20understand%20and%20maintain</a> </div><div class=""><br class=""></div><div class="">But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid.</div><div class=""><br class=""></div><div class="">Please share what you know about it, many appreciations!</div><div class=""><br class=""></div><div class="">Background of my CPS necessarity: </div><div class=""><br class=""></div><div class="">Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Compl</div><div class=""><br class=""></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">Haskell-Cafe mailing list</span><br class=""><span class="">To (un)subscribe, modify options or view archives go to:</span><br class=""><span class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank" rel="noreferrer" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a></span><br class=""><span class="">Only members subscribed via the mailman list are allowed to post.</span></div></blockquote></div>_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank" rel="noreferrer" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">
Haskell-Cafe mailing list<br class="">
To (un)subscribe, modify options or view archives go to:<br class="">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
_______________________________________________<br class="">Haskell-Cafe mailing list<br class="">To (un)subscribe, modify options or view archives go to:<br class=""><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br class="">Only members subscribed via the mailman list are allowed to post.</div></blockquote></div><br class=""></body></html>