Examples of Continuation monad that impossible to understand and maintain?

YueCompl

31 Aug 2021 31 Aug '21

10:03 a.m.

Dear Cafe, 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:

...

Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... of the Continuation monad can produce code that is impossible to understand and maintain> 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. Please share what you know about it, many appreciations! Background of my CPS necessarity: 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. Thanks, Compl

Attachments:

attachment.html (text/html — 2.2 KB)

Show replies by date

Jeff Clites

31 Aug 31 Aug

2:46 p.m.

New subject: Examples of Continuation monad that impossible to understand and maintain?

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. For example, imagine you started with this code snippet: let x = f a y = g x in h x y 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. 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. Jeff

...

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe wrote:

Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ 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.

YueCompl

1 Sep 1 Sep

6:25 a.m.

New subject: Examples of Continuation monad that impossible to understand and maintain?

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. 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"?

...

On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...
Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... of the Continuation monad can produce code that is impossible to understand and maintain>

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

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.

Isaac Elliott

7:55 a.m.

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. On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, < haskell-cafe@haskell.org> wrote:

...

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.

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"?

On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ 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.

_______________________________________________ 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.

_______________________________________________ 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.

YueCompl

8:31 a.m.

Am I understanding it right that all ways upward since the monad layer (assuming all laws are strictly followed) of "Continuation monad", the programmer is restricted to "structured programming" practices, unless he/she resort to the continuation mechanism beneath the monad layer, only in where `goto` is available? I think I can relax if that's the case, CPS is inevitable in this case of mine, and I can at least hide its unsafety beneath the Continuation monad from junior developers in my team.

...

On 2021-09-01, at 15:55, Isaac Elliott wrote:

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.

On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, mailto:haskell-cafe@haskell.org> wrote: 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.

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"?

...
On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...
Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Isaac Elliott

8:54 a.m.

If you hide the usages of callCC behind a sound API then it shouldn't be much of an issue, if that's what you're saying. On Wed, 1 Sep 2021, 6:32 pm YueCompl, wrote:

...

Am I understanding it right that all ways upward since the monad layer (assuming all laws are strictly followed) of "Continuation monad", the programmer is restricted to "structured programming" practices, unless he/she resort to the continuation mechanism beneath the monad layer, only in where `goto` is available?

I think I can relax if that's the case, CPS is inevitable in this case of mine, and I can at least hide its unsafety beneath the Continuation monad from junior developers in my team.

On 2021-09-01, at 15:55, Isaac Elliott wrote:

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.

On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, < haskell-cafe@haskell.org> wrote:

...
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.

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"?

On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ 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.

_______________________________________________ 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.

_______________________________________________ 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.

YueCompl

9:10 a.m.

Ah, yes, I provide a couple of `callCC` equivalent APIs but I think I'll documented them clearly as "advanced" API, besides other more business-oriented, "safe" APIs.

...

On 2021-09-01, at 16:54, Isaac Elliott wrote:

If you hide the usages of callCC behind a sound API then it shouldn't be much of an issue, if that's what you're saying.

On Wed, 1 Sep 2021, 6:32 pm YueCompl, mailto:compl.yue@icloud.com> wrote: Am I understanding it right that all ways upward since the monad layer (assuming all laws are strictly followed) of "Continuation monad", the programmer is restricted to "structured programming" practices, unless he/she resort to the continuation mechanism beneath the monad layer, only in where `goto` is available?

I think I can relax if that's the case, CPS is inevitable in this case of mine, and I can at least hide its unsafety beneath the Continuation monad from junior developers in my team.

...
On 2021-09-01, at 15:55, Isaac Elliott mailto:isaace71295@gmail.com> wrote:

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.

On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, mailto:haskell-cafe@haskell.org> wrote: 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.

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"?

...
On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...
Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Andreas Källberg

3 Oct 3 Oct

5:04 a.m.

You can even implement goto on top of Cont. See for example this: https://www.reddit.com/r/haskell/comments/1jk06q/goto_in_haskell/

...

On 1 Sep 2021, at 15:55, Isaac Elliott wrote:

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.

On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, mailto:haskell-cafe@haskell.org> wrote: 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.

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"?

...
On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...
Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ 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.

YueCompl

8 Oct 8 Oct

11:53 a.m.

No surprise that both "goto" and "continuation" are enemies of "structured programming". But the reddit post says that Python generators can also be used to implement "goto", which I don't get how? I'd regard generator as a "safe" control flow mechanism w.r.t. structured programming, can it really escape? How?

...

On 2021-10-03, at 13:04, Andreas Källberg wrote:

You can even implement goto on top of Cont. See for example this: https://www.reddit.com/r/haskell/comments/1jk06q/goto_in_haskell/ https://www.reddit.com/r/haskell/comments/1jk06q/goto_in_haskell/

...
On 1 Sep 2021, at 15:55, Isaac Elliott mailto:isaace71295@gmail.com> wrote:

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.

On Wed, 1 Sep 2021, 4:31 pm YueCompl via Haskell-Cafe, mailto:haskell-cafe@haskell.org> wrote: 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.

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"?

...
On 2021-08-31, at 22:46, Jeff Clites via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

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.

For example, imagine you started with this code snippet:

let x = f a y = g x in h x y

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.

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.

Jeff

On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe mailto:haskell-cafe@haskell.org> wrote:

...
Dear Cafe,

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:

...
Abuse of the Continuation monad can produce code that is impossible to understand and maintain.

Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text... https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text...

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.

Please share what you know about it, many appreciations!

Background of my CPS necessarity:

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.

Thanks, Compl

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

1367

Age (days ago)

1405

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Andreas Källberg
Isaac Elliott
Jeff Clites
YueCompl

Examples of Continuation monad that impossible to understand and maintain?

tags

participants (4)