3 ms·
I'm not if sure if this is what you're asking for, but to make it very explicit, e.g. Console Output might be modeled as data ConsoleOutput = PrintL
by Quekid5 1y ago
I'm not if sure if this is what you're asking for, but to make it very explicit, e.g. Console Output might be modeled as
data ConsoleOutput =
PrintLn String
| PrintWithMode (Mode * String)
| ...
where | is another spelling of + (which is pretty standard if you look at boolean algebra) and the product is the usual tuple constructor. The is a simple algebraic data type which defines 'an effect' ... it doesn't define the semantics (that's defined by a handler), but it's an 'api' for an effect of some sort.
Obviously, the above definition is a bit contrived, but that's my understanding of why these things are called 'algebraic' effects. It's not that ConsoleOutput and ConsoleInput (however you define that using + or *) are magically 'composable' just because they're both algebraic... for that composition you need extra rules (however you specify that) because effects don't (in general) compose.
- oisdk 1y ago> that's my understanding of why these things are called 'algebraic' effects. This is a misconception. Algebraic effects are not algebraic because they come from algebraic data types, the two features are completely independent (you can have algebraic effects without algebraic data types and vice versa). > It's not that ConsoleOutput and ConsoleInput (however you define that using + or *) are magically 'composable' just because they're both algebraic... for that composition you need extra rules (however you specify that) because effects don't (in general) compose. Actually, if you have two algebraic effects they can automatically compose. And this is a consequence of them both being algebraic. It's just that an algebraic effect is unrelated to an algebraic data type.
- Quekid5 1y agoAre we just talking MTL style then? Because those compose in some sense, but ... it might not be in the sense anyone actually wants.