Algebraic Effects for the Rest of Us • Hacker News Board

Re: Algebraic Effects for the Rest of Us

#41

Post by phoe-krk » Wed, Jul 24, 2019, 9:13 AM UTC

tiborsaas wrote: post #40

phoe-krk wrote: post #38

Earlier quoted context omitted.

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.

Probably just bitterness from the general trend of reinventing everything in computer science, all the time. People who are unaware of former work on any given topic are forced to reinvent it, poorly. People who are aware of it are forced to watch everyone else reinvent them.

Without any sarcasm, communication is a hard and unsolved problem in general.

Re: Algebraic Effects for the Rest of Us

#42

Post by kybernetikos » Wed, Jul 24, 2019, 9:18 AM UTC

rocqua wrote: post #34

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 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 about apparently straight through local code in order to gain the benefits (imagine you check a condition that your later code relies on and then call a log function that unbeknownst to you happens to use effects and doesn't return control until much later when the condition no longer holds?) Can we provide timeouts to effects? Get progress updates? Where should we use effects and where should we use dependency injection? Can library code detect whether handlers are installed for the effects it might want to use up front and fail fast or provide defaults if they aren't there? Will our debuggers understand? What are the practical best practices to avoid the kind of insane spaghetti that this seems to invite?

Re: Algebraic Effects for the Rest of Us

#43

Post by mjburgess » Wed, Jul 24, 2019, 9:20 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…

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.

Re: Algebraic Effects for the Rest of Us

#44

Post by laughinghan » Wed, Jul 24, 2019, 9:26 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…

Reinventing? The post repeatedly cites prior art, particularly OCaml.

The author is likely unaware of Common Lisp's condition system because that's a completely random and arbitrary conceptual ancestor. It was predated by throw/callcc in Standard ML in particular, I believe (which, needless to say, draws a direct line to OCaml and thus this post). In fact, continuations in some form or another date back to 1964 according to: https://en.wikipedia.org/wiki/Continuation#History

Re: Algebraic Effects for the Rest of Us

#45

Post by phoe-krk » Wed, Jul 24, 2019, 9:27 AM UTC

mjburgess wrote: post #43

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…

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.

Re: Algebraic Effects for the Rest of Us

#46

Post by amelius » Wed, Jul 24, 2019, 9:29 AM UTC

Where does the name come from? The word "effects" makes me think of "side effects", which is something I'd usually like to avoid.

Re: Algebraic Effects for the Rest of Us

#47

Post by wruza » Wed, Jul 24, 2019, 9:33 AM UTC

tiborsaas wrote: post #36

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

I better wait a decade, it ain’t much competition since we’re all in the same boat. It’s nice that many are happy with what we have now, but I don’t understand why you dismiss this suggestion so easily (and superficially, as it seems).

Wasm doesn’t allow 1+2, since browsers dictate how io/device/extension-communicating code should be done and their native routines are not ready for techniques of the level higher than just a bare callback. Wasm is not a solution, since the platform and primitives are the same. It is basically the same javascript-in-a-browser model with syntax and scoping rules to be implemented by someone else.

One can emulate any language by turning js/wasm into a virtual machine, but that’s not speed or battery-friendly.

Re: Algebraic Effects for the Rest of Us

#48

Post by [deleted] » Wed, Jul 24, 2019, 9:33 AM UTC

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…

[deleted]

Re: Algebraic Effects for the Rest of Us

#49

Post by ragerino » Wed, Jul 24, 2019, 9:38 AM UTC

In Java you simply extend an Exception class (checked or unchecked) and handle it properly regardless of the error message.

Modern IDEs can detect exception types which don't exist yet, and create them on the fly while you try to use them for the first time.

Re: Algebraic Effects for the Rest of Us

#50

Post by contravariant » Wed, Jul 24, 2019, 9:50 AM UTC

ragerino wrote: post #49

In Java you simply extend an Exception class (checked or unchecked) and handle it properly regardless of the error message. Modern IDEs can detect exception types which don't exist yet, and create them on the fly while you try to use them for the first time.

This would be a replacement if Java had the concept of a continuation, but as far as I know that isn't the case.

Although in this case it simply seems a way to interact with some kind of environment, which in object oriented languages is easily achieved with dependency injection (which does mean you have to pass through an extra argument to every function, but that's not usually that big a problem, and it can give hints on how to combine and divide environments).