4 ms·

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 v

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.

dvt 3y ago
> loops are typed gotos, so are if statements, so, really are functions. 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/EWD215.html 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.
Turskarama 3y ago
The big difference here is to understand the program with Algebraic effects you now need to know _where the code was called from_. 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?
- duped 3y ago
  > Does that mean part of the function signature needs to include that the call stack must be able to handle the effect? Some people would argue that the effects a function may raise are indeed a part of a function's type and for it to type check it must be within scope of a handler for that effect. Think of it like function coloring, a function with the "async/await" effect means all callees must be invoked either within an "async" block (another function with the await effect) or within scope of a runtime that handles the effect. But even that is a bit limiting. > And if that's part of the call stack, why not just make that an explicit function? This is kind of a meaningless question depending on how you formulate it, because the big thing about things like effects is that the callee both returns more than once and is called more than once - so the notion of a "call stack" is kind of meaningless. For example if f calls g and g raises E1 and then E2, f can declare a handler for E1 which moves it into a different scope that has a handler for E2. From the perspective of g() there is no function to call to deal with E1 and E2, since it's the responsibility of the caller to determine that.
  - Turskarama 3y ago
    I think if you wanted to get weird with the control flow like this you might as well make a state machine. All of this seems to be completely missing the reason we even have stack based programs to begin with: they are inherently easier for programmers to reason about. I think these effects would ultimately lead to a bunch of hard to find bugs, all to replace the functionality of a callback.

dvt 3y ago

> loops are typed gotos, so are if statements, so, really are functions. 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/EWD215.html 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.

Turskarama 3y ago

The big difference here is to understand the program with Algebraic effects you now need to know _where the code was called from_. 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?

duped 3y ago
> Does that mean part of the function signature needs to include that the call stack must be able to handle the effect? Some people would argue that the effects a function may raise are indeed a part of a function's type and for it to type check it must be within scope of a handler for that effect. Think of it like function coloring, a function with the "async/await" effect means all callees must be invoked either within an "async" block (another function with the await effect) or within scope of a runtime that handles the effect. But even that is a bit limiting. > And if that's part of the call stack, why not just make that an explicit function? This is kind of a meaningless question depending on how you formulate it, because the big thing about things like effects is that the callee both returns more than once and is called more than once - so the notion of a "call stack" is kind of meaningless. For example if f calls g and g raises E1 and then E2, f can declare a handler for E1 which moves it into a different scope that has a handler for E2. From the perspective of g() there is no function to call to deal with E1 and E2, since it's the responsibility of the caller to determine that.
- Turskarama 3y ago
  I think if you wanted to get weird with the control flow like this you might as well make a state machine. All of this seems to be completely missing the reason we even have stack based programs to begin with: they are inherently easier for programmers to reason about. I think these effects would ultimately lead to a bunch of hard to find bugs, all to replace the functionality of a callback.