Algebraic Effects – You Can Touch This (2019)
jacek.zlydach.pl
jacek.zlydach.pl
This reminds me of the arguments for call/cc in scheme. A very general construct! It can implement exceptions, backtracking, it can even implement "if", so "if" wouldn't even need to be primitive. You know what else lets you do all that? Good old GOTO.
I don't care about "power" for a language construct. I need guarantees a lot more. Does using this construct allow me to put some things in the "that doesn't matter here" bin, so I can focus on some things without worrying about everything at once? GOTO is better at punching holes in bins of compartmentalization, and call/cc isn't much better.
I don't know much about algebraic effects, but usually "algebraic" implies various guarantees about composability and idempotence, which are exactly what you want when dealing with state and the world.
Algebraic effects are less general and play nicer with scoped constructs like finalizers and exceptions. The downside is that they work via stack unwindindig, so they incur some performace penalties.
I highly recommend reading the original article - "Algebraic Effects for the Rest of Us". It demonstrates their operation via Javascript by renaming try/catch, and I think it will answer your questions nicely.
That said, the article didn't make me much wiser on what's the point. I could sort of see it if it came with guarantees in the type system, I guess.
Imho, it's the same deal as with monads: Outside of pure functional languages with a strong type system there is not much appeal. But for e.g. a Haskell programmer its like the next coming of christ...
But I think it could be very useful if combined with the equivalent of javas checked exceptions, even in other languages.
Something like "fun readFile(Name: Path):String performs FS.open, FS.read, FS.close throws FileNotFound, FileRead, ..."
A bit excessive, but potentially very useful for all kinds of error checking.
Are you sure about that?
Assembly lets you jump anywhere, not bound by any scope, because it doesn't have scopes in any real sense.
C and Pascal, if I recall correctly, only let you goto somewhere else in the same function.
Don't know about other languages...
Goto tags and blocks/return-from have lexical scope and dynamic extent. Lexical scope means that one can goto to enclosing goto tags and one can return from enclosing blocks. "dynamic extent" means that corresponding scoping constructs tagbody and block not have been exited yet.
CATCH/THROW has dynamic scope and dynamic extent. Means that the CATCH targets will be looked up on the stack.
Then Common Lisp has UNWIND-PROTECT, which sets up a dynamic scope. When leaving this scope by a non-local control transfer, it is ensured that some specified code will be executed.
These are then building blocks for higher-level control, like the Condition System, which provides condition types, handlers, restarts, ... which is used then for error handling, where on error the stack is left like it is.
> Assembly lets you jump anywhere
it's just that jumping to some arbitrary place might not make sense.
It really depends on the language and what kind of goto you mean.
But in the context of the post I replied to, yes, because you cannot replace algebraic effects with "neutered" gotos (like the ones in c), you need the equivalent of longjmp, or maybe gosub.
You can obviously design a language where goto does implicitely run finalizers or does similar fancy stuff, but this is again leaving the scope of the original discussion I think...
I've been doing this year's Advent of Code in Unison (https://unison-lang.org/, no affiliation) and I've found the form of algebraic effects used there (Abilities in Unison parlence) great for "that doesn't matter here".
For example, the `Abort` ability allows me to stop control flow deep down inside my code at without having to "thread" a bunch of monads or Maybes or Eithers through all the intermediate layers.
In one case I also used the `Store` ability to accumulate some metadata about a simulation as it progressed without having to "pollute"[^1] all of the intermediate layers with explicit handling of the metadata.
[^1]: the abilities do appear in the type signatures, though.
https://www.unison-lang.org/learn/fundamentals/abilities/
https://share.unison-lang.org/@unison/p/code/latest/namespac...
Conditions and restarts aren’t much better or worse than standard exceptions in that[1] respect.
You can basically implement them[2] on top of those + dynamic scope: the gist is that when an exceptional condition happens, instead of destructively unwinding the stack immediately the code only invokes a callback (selected by condition type, installed by some dynamically enclosing code), which then can choose one of the available handling strategies and unwind the stack to the requisite point (using try / throw if implementing on top of that). The fun part is that it can unwind less than to the point where the callback was installed: e.g. a REPL installs a handler that, on an undefined variable error, asks the user interactively for the value to use instead, invokes the language-provided USE-VALUE restart and proceeds; no debugger-level carnal knowledge of the language runtime is necessary at any point. (Compare also the DOS abort/retry/ignore prompt. Win32 SEH is also capable of expressing a certain degree of resumable exceptions not exposed by C++ runtime, as seen in classic VB’s On Error Resume Next—though that is admittedly a bad idea.)
The advantage[3] of this construct is that it enables you to structure APIs differently, in that the knowledge of how to recover need not exist at the same level as the decision to recover that way. (The potential recovery strategies become part of the API the same way that potential errors are.) That eliminates the “handle-those-errors-this-way” flag awkwardness that exception handling can’t really mitigate. The API-design expressive power, so to say, is different even if the control-flow expressive power[4] is basically the same.
(A minor point is that because there’s no mandatory unwinding, the signalling code can also decide to proceed if the condition is unhandled. This subsumes warning systems such as the one in Python[5]. The point is minor because I haven’t seen those play an important role.)
> I don't know much about algebraic effects, but usually "algebraic" implies various guarantees about composability and idempotence, which are exactly what you want when dealing with state and the world.
The guarantees of composability are the point, yes—compared to monad transformers. In that respect the article, to me, seems to miss some of the point of the algebraic effects research: the languages there usually try to isolate all non-referentially-transparent execution in the effect system, not to introduce it as an additional system. This includes ordinary mutability (of things that outlive a function call, you’re free to mutate temporaries as long as you destroy them at the end). The ultimate in function colouring, so to say. Monads were a previous attempt at the same, and monad transformers do add some composability to them, but using the result kind of sucks. We’ll see how well effects do.
Algebraic effects are also more powerful than resumable exceptions, because exception resumption is usually one-shot—either you resume or you don’t—whereas both Eff and Koka allow you to define a nondeterminism effect that allows you to resume more than once (e.g. for backtracking).
I’d still say the article’s point is interesting, because conditions systems originate from the Lisp tradition and so there doesn’t seem to be a lot of literature on typing them statically. It’s nice to realize that research has already been done under the banner of typing algebraic effects.
[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[2] https://news.ycombinator.com/item?id=31196046
[3] https://gigamonkeys.com/book/beyond-exception-handling-condi...
I still don't understand how effects allow taming mutability. Can you point me to some resource (possibly understandable by a layman without knowledge of advanced type theory)?
> The only reward for the hard work to capture the whole continuation efficiently is more hard work to get around the capture of the whole continuation. Both the users and the implementors are better served with a set of well-chosen control primitives of various degrees of generality with well thought-out interactions.
Also, if React hooks is the way to describe UI components, I think the mechanism behind it should be either formalised as a proper language feature in JS or in some new language used for frontend development. For example, I noticed this teaser bit in the first materials about Verse: "The full Verse language also has a statically-checked effect system, including both mutable references and input/output." https://simon.peytonjones.org/verse-calculus/ Discussed earlier here: https://news.ycombinator.com/item?id=33946933
Or is this something that e.g. ClojureScript with Reagent already formalises and we all should study that?
I guess what js needs is an actual proper language level immutable type, and it wouldn't need all the hooks trickery?
„I have a partial understanding of a related concept and zero knowledge on the actual topic, so let me write a blog post“
CL condition system is a strict subset of algebraic effects (or any effect system)
Would you prefer me to not write about related concepts I do know about, or just to omit the disclaimer next time and confidently pretend I know everything?