Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algebraic Effects for the Rest of Us

overreacted.io

Post reply on HN
Print view View original

81–90 of 106 posts

Re: Algebraic Effects for the Rest of Us

#81

Post by lispm »

codebje wrote: post #65
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…

Common Lisp's condition system was first described in '83 for the Lisp Machine in a technical report that's hard to get one's hands on these days. It was described in an MIT AI Labs working paper a few years later by Pitman ( https://dspace.mit.edu/handle/1721.1/41474 ). Algebraic effects were introduced by Plotkin in 2001 ( https://link.springer.com/chapter/10.1007/3-540-45315-6_1 ) as an extension of Moggi's 1991 w…

> first described in '83 for the Lisp Machine

The Symbolics Lisp Machine Manual from 1984 documents the condition system for the Lisp OS written in Zetalisp:

http://bitsavers.org/pdf/symbolics/software/release_5/3B_Lis...

See the chapter 'COND' in Volume 3B, 'Lisp Language'

Re: Algebraic Effects for the Rest of Us

#82

Post by lispm »

TeMPOraL wrote: post #26
riffraff wrote: post #4

Earlier quoted context omitted.

Smalltalk also had resumable exceptions, and I remember implementing then in ruby too, with callcc, but I think algebraic effects are more general and by focusing on exceptions the author has sort of hidden that, even if he kept saying it's just an example.

Like reikonomusha said, CL's condition system is pretty general in itself. The naming choice isn't an accident - the thing that's being "raised" is a "condition" (of which "error" is just a subtype), and what you do with a condition is "signal" it. In CL, most of the time it's used for exception handling, but I've seen code using this system for tasks not related to errors. As a simple example, you can imagine data p…

Note also that this mechanism is usually hidden behind a macro. In user code one would just write:

    (with-progress-noted (datum data)
      (process-partial-data datum))
And this then would expand into a machinery like above.

The Lisp Machine OS had a system-wide progress bar at the bottom of the screen, which then would show the progress of some process - usually the front process or something related.

Re: Algebraic Effects for the Rest of Us

#83

Post by ufo »

chc4 wrote: post #9

Maybe I'm missing something, but isn't this essentially just coroutines? In Lua you can do `myFile = coroutine.yield("get a file")` to pause your coroutine, and when the caller does `coroutine.resume(someFile)` it's resumed with the value passed in. EDIT: I guess the difference would be in Lua, yields return to where they were resumed each time, while in algebriac effects they return to the nearest handler for that c…

Coroutines are a mechanism that you can use to implement algebraic effects. When the coroutine yields, it yields the tagged effect object which can be used to determine what effect handler to run, and after that whether to resume the evaluation of the coroutine or not.

One obvious difference is that in a statically-typed language with algebraic effects the compiler checks that all the effects are being handled correctly. If you implement these in raw Lua a stray "coroutine.yield" can ruin everything if it doesn't return a properly formed tagged event object.

Re: Algebraic Effects for the Rest of Us

#84

Post by jules »

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…

The essential feature of algebraic effects is that the restarts can be passed around as first class values resumed multiple times. Can CL do that?

Re: Algebraic Effects for the Rest of Us

#85

Post by coldtea »

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…

Of course the failure could as well be on the Lisp / ANSI Common Lisp people. They had a concept 25+ years ago, and failed to promote it properly.

Re: Algebraic Effects for the Rest of Us

#86

Post by coldtea »

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?

React might be a UI library, but the post doesn't describe the concept in terms of application in a UI library, but as a general concept (examples given include logging and exception handling, and are not tied to UI needs).

Second, React might be a UI library, but its need / uses / limits in using for something like "algebraic effects" could be similar to the ones encountered 30+ years ago in non-UI domains.

Not to mention the biggest fault in this comment: the domains where Dan got the idea of Algebraic Effects from are already non UI -- he got it from functional programming research in non-UI specific domains and languages.

Which means that he could just as well use the original, also non-UI, concepts, was he aware of them.

A more valid response along your reasoning would be that of course not everybody can/knows every prior art. That's true, and valid. But the argument that prior art is not relevant in this case because we're talking about UI is not...

>It's a nice trivia, but what should we do with this information?

Evaluate it, enrich our understanding of it, find prior uses and limits (and not just the current re-implementation of the concept) and so on?

Re: Algebraic Effects for the Rest of Us

#87

Post by xvilka »

Well, OCaml it the only mainstream language that works on the integration of the algebraic effects. But the work[1] is being done is very slow for a project of such importance (it is also a part of multicore). Nevertheless, OCaml loses some points to Rust, due to its lack of proper parallelism. So I hope Rust ecosystem would put more attention to the efforts[2][3][4] to bring algebraic effects to the language.

[1] https://github.com/ocaml-multicore/ocaml-multicore/projects/...

[2] https://github.com/pandaman64/effective-rust

[3] https://kcs1959.jp/archives/4387/general/algebraic-effects-f...

[4] https://qiita.com/__pandaman64__/items/9fd47af5a39f0d2a6bbb

Re: Algebraic Effects for the Rest of Us

#88

Post by dleslie »

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…

I was thinking throughout reading this: "Isn't this just call/cc?"

Re: Algebraic Effects for the Rest of Us

#89

Post by dleslie »

jules wrote: post #84
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…

The essential feature of algebraic effects is that the restarts can be passed around as first class values resumed multiple times. Can CL do that?

Scheme certainly can, via call/cc

Re: Algebraic Effects for the Rest of Us

#90

Post by gumby »

Instead of ES2025 he should have used "ES1978" because the early lisp signalling systems were more general than just errors and had continuable exceptions. This evolved into the Common Lisp Object System when Common Lisp was standardized in the early 1980s.
Post reply on HN