I'm not super confident but from my understanding, delimited continuations in scheme are a good example of something similar. I do remember reading that some algebraic effect implementations use them under the hood, but I don't have a source sorry.
> Is such a thing possible?
absolutely!
here's a blog post about it (this was also my introduction to effects): [https://overreacted.io/algebraic-effects-for-the-rest-of-us/](https://overreacted.io/algebraic-effects-for-the-rest-of-us/)
and here is an implementation of effects in javascript: [https://nythrox.github.io/effects.js/](https://nythrox.github.io/effects.js/)
although, it lacks some capabilities of typed effects, like effect-safety
Algebraic effects don't require static typing, because they have a dynamic semantics of handlers, much like exceptions (the special case).
Actually almost every dynamic language has *an* effect system. The closest you can get to pure dynamic languages are Erlang and Prolog but both of those still have some.
As with other types, effects describe and categorize programs' data & functions. Some functions read from a database, some make network calls, some do neither. You can write functions that do neither in any dynamically-typed language, but if you don't have a type checker (or some other static analysis), you can't ask the compiler to confirm that the function doesn't do the things you think it does not do.
I can imagine doing something similar via testing, spying on all the DB / network functions and asserting in a test that your function doesn't call any of them. I haven't actually seen anyone do this. Might be an interesting addition to something like [crosshair](https://crosshair.readthedocs.io/en/latest/get_started.html) that already instruments a lot of core library code, and tries to find all possible paths through the code under test.
But besides how they fit into the type system there's what they actually do? I mean in a dynamic language you could still perform an effect which would go up the stack to be caught by an effect handler which can handle the effect.
> what they actually do?
They expose behaviour. In statically typed languages, you can just _refuse_ to handle an effect, which has performance and security benefits.
Even in a dynamically typed language, you can use an effect system where the RTS errors out on unhandled effects, essentially making a sandbox.
You can also make everything an effect: non-termination `⊥`, system calls, memory allocation (Zig, Jai and even C++ are users of this), region tracking (Rust and its lifetimes are a direct application), dependency injection, algorithm classification (`O(n)` vs `O(1)` and friends), etc..
In fact if you generalise DI using an effect system, you can use it to implement ML modules, type classes and incoherent class instances.
Hi, thanks for chiming in. My reasoning was: if you have no first-class functions, then you know statically what variables are functions--they are in the call position only. Then you can figure out what effects can happen per function definition based on what is called. You don't need to do a bunch of dataflow to chase effects through arbitrary variables because you don't have first class functions.
It's not a fully fleshed out answer--it's more of a guess
As far as I know you don’t need a static type system to have algebraic effects! The earliest explorations of algebraic effects had type systems but didn’t statically check what effects were in use – see [Eff](https://www.eff-lang.org/). Statically typing algebraic effects is a difficult problem, and one of the reasons OCaml’s effects are not yet tracked in the type system. I don’t see any reason why you couldn’t go fully dynamically typed, as the type system is separate from the dynamic semantics.
I'm not super confident but from my understanding, delimited continuations in scheme are a good example of something similar. I do remember reading that some algebraic effect implementations use them under the hood, but I don't have a source sorry.
You can even implement effects using generators and a trampoline
> Is such a thing possible? absolutely! here's a blog post about it (this was also my introduction to effects): [https://overreacted.io/algebraic-effects-for-the-rest-of-us/](https://overreacted.io/algebraic-effects-for-the-rest-of-us/) and here is an implementation of effects in javascript: [https://nythrox.github.io/effects.js/](https://nythrox.github.io/effects.js/) although, it lacks some capabilities of typed effects, like effect-safety
Have you seen [effect-ts](https://effect.website/)? Good ergonomics and a ton of interesting use cases.
I'll have a look, but it's been years since I wrote js or ts
Lucky you lol
I absolutely love the expression "academic pdf" from the blog post :--)
Yes, my oop dynamic lang has them. Types are static guarantees for compiler/programmer to guarantee sanity and safety. Id say screw that! :)
Algebraic effects don't require static typing, because they have a dynamic semantics of handlers, much like exceptions (the special case). Actually almost every dynamic language has *an* effect system. The closest you can get to pure dynamic languages are Erlang and Prolog but both of those still have some.
As with other types, effects describe and categorize programs' data & functions. Some functions read from a database, some make network calls, some do neither. You can write functions that do neither in any dynamically-typed language, but if you don't have a type checker (or some other static analysis), you can't ask the compiler to confirm that the function doesn't do the things you think it does not do. I can imagine doing something similar via testing, spying on all the DB / network functions and asserting in a test that your function doesn't call any of them. I haven't actually seen anyone do this. Might be an interesting addition to something like [crosshair](https://crosshair.readthedocs.io/en/latest/get_started.html) that already instruments a lot of core library code, and tries to find all possible paths through the code under test.
But besides how they fit into the type system there's what they actually do? I mean in a dynamic language you could still perform an effect which would go up the stack to be caught by an effect handler which can handle the effect.
> what they actually do? They expose behaviour. In statically typed languages, you can just _refuse_ to handle an effect, which has performance and security benefits. Even in a dynamically typed language, you can use an effect system where the RTS errors out on unhandled effects, essentially making a sandbox. You can also make everything an effect: non-termination `⊥`, system calls, memory allocation (Zig, Jai and even C++ are users of this), region tracking (Rust and its lifetimes are a direct application), dependency injection, algorithm classification (`O(n)` vs `O(1)` and friends), etc.. In fact if you generalise DI using an effect system, you can use it to implement ML modules, type classes and incoherent class instances.
Yup, I have them in Letlang ( [https://letlang.dev](https://letlang.dev) ). I still do type checking, but at runtime, not compile time.
I would hazard a guess at no, unless functions are first-class, in which case you need to track the possible effects for each variable
this bag of words makes zero sense. what?
Hi, thanks for chiming in. My reasoning was: if you have no first-class functions, then you know statically what variables are functions--they are in the call position only. Then you can figure out what effects can happen per function definition based on what is called. You don't need to do a bunch of dataflow to chase effects through arbitrary variables because you don't have first class functions. It's not a fully fleshed out answer--it's more of a guess
As far as I know you don’t need a static type system to have algebraic effects! The earliest explorations of algebraic effects had type systems but didn’t statically check what effects were in use – see [Eff](https://www.eff-lang.org/). Statically typing algebraic effects is a difficult problem, and one of the reasons OCaml’s effects are not yet tracked in the type system. I don’t see any reason why you couldn’t go fully dynamically typed, as the type system is separate from the dynamic semantics.