Algebraic Effects for the Rest of Us

Post by mjburgess » Wed, Jul 24, 2019, 5:09 PM UTC

phoe-krk wrote: post #45

mjburgess wrote: post #43

Earlier quoted context omitted.

Algebraic Effects are not common lisp's condition system. They are far more general. The example here to do with error handling only shows that this form of error handling is an (incredibly) specific (very limited) instance. And nothing is being reinvented here. This is an article to communicate, in the simplest terms possible, decades of academic research. The author is not claiming to, nor has he, invented anything…

Lisp's condition system isn't just for handling errors either; it's an system for handling conditions, just as the name suggests.

Post by chowells » Wed, Jul 24, 2019, 5:53 PM UTC

kybernetikos wrote: post #42

rocqua wrote: post #34

Earlier quoted context omitted.

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 t…

That explains why one of his examples is a log handler, which in javascript would be sensibly provided by dependency injection, but that doesn't work as well for haskell. Things I'd want more information on: what about errors in effect handlers (or would errors be reimplemented as effects?), effects with no handler, which handlers do effects inside handlers use? Is it really worth making it much harder to reason abou…

Post by chombier » Wed, Jul 24, 2019, 6:28 PM UTC

gumby wrote: post #91

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…

> Near the end of the article: >> Because algebraic effects are coming from statically typed languages, Though in fact the origins come from dynamically typed languages like Lisp, where condition signalling systems were developed in the 1970s. When they started appearing in statically typed languages in the late 80s, they were only used for errors, and by the time they were caught the stack had already been unwound.…

Post by catern » Wed, Jul 24, 2019, 7:23 PM UTC

fjfaase wrote: post #6

I doubt if you need any new language construct to introduce this. Could you not simply pass an error handling function/object with all your functions/methods, which is called when an error occurs? This function/object could then resolve the error or throw an exception if it cannot resolve the error. It is possible, and relatively easy, to chain such error handling functions/methods to implement complex error handling…

Post by codebje » Wed, Jul 24, 2019, 9:04 PM UTC

gumby wrote: post #97

chombier wrote: post #96

Earlier quoted context omitted.

Sure but I mean most work on algebraic effects (or at least the papers I know of) deals with the associated type system . Instead most people here seem to focus on the semantics, which indeed boil down to call/cc + handlers or previous condition systems.

Those 1970s/1980s conditioning systems specifically evolved from the inheritance-based type systems originally developed for object-oriented systems. Computer science is a field that notoriously ignores the past, so these folks are far from the only people to reinvent something already well developed.