Algebraic Effects for the Rest of Us • Hacker News Board

Re: Algebraic Effects for the Rest of Us

#31

Post by LeonidasXIV » Wed, Jul 24, 2019, 8:32 AM UTC

ww520 wrote: post #30

phoe-krk wrote: post #19

> The best we can do is to recover from a failure and maybe somehow retry what we were doing, but we can’t magically “go back” to where we were, and do something different. But with algebraic effects, we can. This is literally Common Lisp's condition system which a) decouples signaling conditions from handling conditions, b) allows you to execute arbitrary code in the place that signals, c) allows you to stack indepe…

Yeah, it's literally a subset of Common Lisp's condition system. With Lisp's closure and continuation, it's easy to implement the feature. When I read the blog, I was wondering is renaming old concepts with exotic names and making them new the trend now?

Unlike the condition system algebraic effects are typed so you can reason about them at compilation time and ensure all of them are at least used somewhat correctly.

It makes quite a bit of difference when I compare e.g. async programming in OCaml with Lwt/Async where I know I've at least hooked up the promises somewhat correctly with e.g. Python or JS where I will notice that it is wrong when the code is executed.

Re: Algebraic Effects for the Rest of Us

#32

Post by ww520 » Wed, Jul 24, 2019, 8:34 AM UTC

reikonomusha wrote: post #3

The author ought to look into and write about the Common Lisp condition system, which allows error handlers to invoke restarts at different parts of the call stack. [1] The long-story-short on them is that they decouple the treatment of exceptional situations (or conditions ) into three orthogonal roles: signaling the condition (akin to “throwing”), handling the condition (akin to “catching”), and recovering from the…

Even Visual Basic has a crude variant in the form of:

    On Error { GoTo N | Resume Next }

Re: Algebraic Effects for the Rest of Us

#33

Post by phoe-krk » Wed, Jul 24, 2019, 8:36 AM UTC

LeonidasXIV wrote: post #31

ww520 wrote: post #30

Earlier quoted context omitted.

Yeah, it's literally a subset of Common Lisp's condition system. With Lisp's closure and continuation, it's easy to implement the feature. When I read the blog, I was wondering is renaming old concepts with exotic names and making them new the trend now?

Unlike the condition system algebraic effects are typed so you can reason about them at compilation time and ensure all of them are at least used somewhat correctly. It makes quite a bit of difference when I compare e.g. async programming in OCaml with Lwt/Async where I know I've at least hooked up the promises somewhat correctly with e.g. Python or JS where I will notice that it is wrong when the code is executed.

> Unlike the condition system algebraic effects are typed

What exactly do you mean? Conditions are typed in Lisp with proper inheritance, and handlers can be bound only to particular types of conditions.

Re: Algebraic Effects for the Rest of Us

#34

Post by rocqua » Wed, Jul 24, 2019, 8:48 AM UTC

chombier wrote: post #24

Near the end of the article: > Because algebraic effects are coming from statically typed languages, much of the debate about them centers on the ways they can be expressed in types. This is no doubt important but can also make it challenging to grasp the concept. That’s why this article doesn’t talk about types at all. I'm only remotely familiar with algebraic effects, but I thought the whole point was to have a nic…

In e.g. Haskell, you often Dont explicitly write out types, letting the compiler infer them for you. This could essentially cascade all the way up.

Meanwhile, if you want to add logging in Haskell via a monad, you don't just need to change the type of each calling function to make it monadic, but you need to rewrite the function to make it monadic. That is harder work than changing some types. Moreover it is harder to automate by an IDE.

Re: Algebraic Effects for the Rest of Us

#35

Post by tiborsaas » Wed, Jul 24, 2019, 8:50 AM UTC

phoe-krk wrote: post #19

> The best we can do is to recover from a failure and maybe somehow retry what we were doing, but we can’t magically “go back” to where we were, and do something different. But with algebraic effects, we can. This is literally Common Lisp's condition system which a) decouples signaling conditions from handling conditions, b) allows you to execute arbitrary code in the place that signals, c) allows you to stack indepe…

> That's reinventing a 25+ year old wheel the author is likely unaware of.

These comments are not helpful. React is a UI library and this concept would be new in this world. Who cares if it's done by the Simpsons already? It's a nice trivia, but what should we do with this information?

Re: Algebraic Effects for the Rest of Us

#36

Post by tiborsaas » Wed, Jul 24, 2019, 8:53 AM UTC

wruza wrote: post #17

Now conditions/restarts. How much more decades should we wait till they rediscover all the programming tools? Please, rewrite your browser legacies once to support non-trivial execution model and allow any decent language to stop this madness.

Step 1) Find a language that can do that

Step 2) Compile it to WebAssembly

Step 3) Validate those input fields

Step 4) Profit

Re: Algebraic Effects for the Rest of Us

#37

Post by pwpwp » Wed, Jul 24, 2019, 8:54 AM UTC

Algebraic effects are similar to Common Lisp restart handlers, but in addition, they also receive the continuation of the invoker. This means, you can use algebraic effect handlers to implement higher-order control features like coroutines, probabilistic programming, and nondeterminism (which you can't in Common Lisp).

However, what most people get wrong: you do not need higher-order control if you just want to resume after an error. This is demonstrated by Common Lisp, which doesn't have coroutines, algebraic effects, nor continuations, but _can_ resume after an error.

The main example of the article could be done just fine in Common Lisp, because it doesn't use any higher-order control.

Re: Algebraic Effects for the Rest of Us

#38

Post by phoe-krk » Wed, Jul 24, 2019, 8:56 AM UTC

tiborsaas wrote: post #35

phoe-krk wrote: post #19

> The best we can do is to recover from a failure and maybe somehow retry what we were doing, but we can’t magically “go back” to where we were, and do something different. But with algebraic effects, we can. This is literally Common Lisp's condition system which a) decouples signaling conditions from handling conditions, b) allows you to execute arbitrary code in the place that signals, c) allows you to stack indepe…

> That's reinventing a 25+ year old wheel the author is likely unaware of. These comments are not helpful. React is a UI library and this concept would be new in this world. Who cares if it's done by the Simpsons already? It's a nice trivia, but what should we do with this information?

The usual. Find out how the concept was successfully implemented before, learn from these implementations' mistakes, and leverage all of that knowledge in your current work.

Re: Algebraic Effects for the Rest of Us

#39

Post by pjc50 » Wed, Jul 24, 2019, 9:00 AM UTC

phoe-krk wrote: post #19

> The best we can do is to recover from a failure and maybe somehow retry what we were doing, but we can’t magically “go back” to where we were, and do something different. But with algebraic effects, we can. This is literally Common Lisp's condition system which a) decouples signaling conditions from handling conditions, b) allows you to execute arbitrary code in the place that signals, c) allows you to stack indepe…

The origin of "algebraic effects" appears to be this paper (Plotkin and Power): https://link.springer.com/article/10.1023%2FA%3A102306490896...

Unfortunately I don't speak monad.

Re: Algebraic Effects for the Rest of Us

#40

Post by tiborsaas » Wed, Jul 24, 2019, 9:05 AM UTC

phoe-krk wrote: post #38

tiborsaas wrote: post #35

Earlier quoted context omitted.

> That's reinventing a 25+ year old wheel the author is likely unaware of. These comments are not helpful. React is a UI library and this concept would be new in this world. Who cares if it's done by the Simpsons already? It's a nice trivia, but what should we do with this information?

The usual. Find out how the concept was successfully implemented before, learn from these implementations' mistakes, and leverage all of that knowledge in your current work.

That's a much nicer, forward pointing comment and it's good to know there's previous act. I've read some bitterness between the lines.