51–60 of 84 posts
Or you can go all the way in the other direction (double- or triple-barreled CPS) and have functions that can't return but only call other functions. let fizzbuzz = func(ret, fizzbuzz, x, max) { (x == max)(ret, func() { let printed = false; (x % 3)(func (t0) { let k0 = func() { (x % 5)(func (t1) { let k1 = func() { let k2 = func() { (x + 1)(func (t2) { fizzbuzz(ret, fizzbuzz, t2, max); }) }; (printed == false)(func (…
Earlier quoted context omitted.
You're not missing anything. Algebraic effects are basically typed gotos†[1][2], and are generally a bad idea to use and/or implement. They can be useful in a few very niche situations when using typed functional languages. † With added asynchronicity. [1] http://community.schemewiki.org/?call-with-current-continuat... [2] Some argue call/cc is, in fact, worse than goto: https://okmij.org/ftp/continuations/against-ca…
loops are typed gotos, so are if statements, so, really are functions. Goto isn't bad, it's integral to programming. It's just too powerful, so we tame it in various ways. Algebraic effects are one of those ways.
All of the above don't break the continuity of a program's control flow. Maybe you should be arguing with Dijkstra, not me: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/E...
Pretty sure we've already litigated that goto/jmp is bad, which is why it's almost never used in modern C/C++ code unless doing very specific things.
OP Might want to look into the origins of this website name.
Maybe calling it 'return' is cursed, but this concept isn't cursed at all. These are resumable exceptions, and I used to love them! Windows supports them natively, although I don't think they're widely used. Here's the C/C++ extension for Window's native "structured exception handling", and ordinary C++ exceptions are built on top of it:
https://learn.microsoft.com/en-us/cpp/cpp/structured-excepti...
It supports:
> Recognize the exception but dismiss it (EXCEPTION_CONTINUE_EXECUTION).
And as a kernel programmer, I really like resumable exceptions -- most hardware exceptions are resumable, and the kernel uses them extensively. When you get a page fault, that's an exception, and the kernel has a handler, and the control flow, um, yeets to the handler, and the handler, well, returns (or exits or whatever you want to call it) right back to the exception site.
And POSIX signals support this too -- it's even the default behavior when a signal handler returns. (POSIX signals suck.)
Earlier quoted context omitted.
> express programs in as few expressions as possible I don't find this appealing on its face. Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain. I suspect that's one of the reasons Lisps (and functional languages in general) haven't caught up in popularity even as it becomes much easier to adopt one for any target and in any organization.
> I don't find this appealing on its face. Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain. In that case, it's more about minimizing the language, rather than the programs. call/cc is a single instruction that is sufficiently expressive to implement e.g. exceptions, coroutines and lots of stuff for which people typically use monad-style embeddings…
The flip side of this is that call/cc prevents you from relying on a stack, except in cases where you can do heavy static analysis. And you virtually never need the full power of call/cc unless you're implementing coroutines.
This is the main reason that so few languages support call/cc: stacks are a nice implementation technique (as opposed to GCed activation records on the heap), and call/cc comes with a heavy price for very situational value.
One alternative are "escape" continuations, which can only be used during the lifetime of the creating block. These are stack friendly.
Or you can go all the way in the other direction (double- or triple-barreled CPS) and have functions that can't return but only call other functions. let fizzbuzz = func(ret, fizzbuzz, x, max) { (x == max)(ret, func() { let printed = false; (x % 3)(func (t0) { let k0 = func() { (x % 5)(func (t1) { let k1 = func() { let k2 = func() { (x + 1)(func (t2) { fizzbuzz(ret, fizzbuzz, t2, max); }) }; (printed == false)(func (…
> Oh, also, functions cannot be recursive (without passing in a function to itself), because we won't have the function bound to a name in the local context when defining itself. Fun, right? The startup accelerator that runs this forum is named after a pretty neat thing you can do with a language that only has anonymous functions: https://en.wikipedia.org/wiki/Fixed-point_combinator
You don't even need that, there is a much more efficient way in a language that supports let-bindings (but not letrec): let f' = func(f, g, other_args...) { // ... g(f, g, whatever...); // ... }; let g' = func(f, g, other_args...) { // ... f(f, g, whatever...); // ... } let f = func(other_args...) { return f'(f', g', other_args...); } let g = func(other_args...) { return g'(f', g', other_args...); } That's basically…
Earlier quoted context omitted.
You're not missing anything. Algebraic effects are basically typed gotos†[1][2], and are generally a bad idea to use and/or implement. They can be useful in a few very niche situations when using typed functional languages. † With added asynchronicity. [1] http://community.schemewiki.org/?call-with-current-continuat... [2] Some argue call/cc is, in fact, worse than goto: https://okmij.org/ftp/continuations/against-ca…
loops are typed gotos, so are if statements, so, really are functions. Goto isn't bad, it's integral to programming. It's just too powerful, so we tame it in various ways. Algebraic effects are one of those ways.
If you ask for an effect to come from higher up the call stack, does that mean part of the function signature needs to include that the call stack must be able to handle the effect?
And if that's part of the call stack, why not just make that an explicit function?
> You can toss it, which works a little differently: it traverses the stack until you reach a matching catch block, but then you can use the return keyword to go back to where the value was tossed from. > > I know, it's cursed using return in this unusual way. Again, sorry, I didn't make you keep reading. But, the reward is that since you got here, you get to see how we can use these to create control flow. Maybe cal…