Roc is getting an effect system, which will be async-capable and will use continuation-passing-style. Wow, terrific news if I understood correctly. Great presentation as always rtfeldman.
This is exactly final encoding vs initial encoding. With algebraic data types, we can pair initial encoding with the interpreter pattern to obtain extensible effects. OOP simulates sum types using ad-hoc polymorphism, so we can pair final encoding and the decorator pattern to obtain extensible effects. I like how Roc automatically extends the tags returned from a function. There is probably an analogue in OCaml, I think it's row polymorphism.
How easy does Roc make it to specify that a piece of code is only allowed to perform some effects but not others? For example, could one specify that when running a database transaction we would allow access to the local file system but not to the network in order to limit task latency while holding a connection open on the database? Presumably this would show up as an explicit type for the third type argument for Task? Would the Roc compiler then present an error at the point where you tried to perform a disallowed task or would it error out at the point where the type was explicitly specified?
The non-capabilities seem like capabilities to me. Effects are specific beasts that need to be distinguished from purely functional code as much as possible.
Yes it is. But I imagine it wont be as ergonomic as this because you would have to implement the Task monad manually everywhere. Most of the functional features of Rust are first class because otherwise using them is not nice. Perhaps if you could derive Task automatically with macros but I'm not a big Rust expert so I don't know.
Roc is getting an effect system, which will be async-capable and will use continuation-passing-style.
Wow, terrific news if I understood correctly. Great presentation as always rtfeldman.
For Rust though, map_err calls can be avoided. But that will come at the cost of writing std::convert::From implementations for each.
I like the effect system + the row polimorphism of Roc 😍
This is exactly final encoding vs initial encoding.
With algebraic data types, we can pair initial encoding with the interpreter pattern to obtain extensible effects.
OOP simulates sum types using ad-hoc polymorphism, so we can pair final encoding and the decorator pattern to obtain extensible effects.
I like how Roc automatically extends the tags returned from a function. There is probably an analogue in OCaml, I think it's row polymorphism.
In OCaml, Polymorphic Variants enable Row Polymorphism.
Great video, Roc sounds really cool!
35:07 isn't this part a monadic bind?
That's just an artefact of the fact that effects can be encoded by monads.
Do syntax would avoid all those Task.await. Event F# has something like that with computation expressions.
Scala3 ZIO in Roc but without the environment, right?
How easy does Roc make it to specify that a piece of code is only allowed to perform some effects but not others? For example, could one specify that when running a database transaction we would allow access to the local file system but not to the network in order to limit task latency while holding a connection open on the database? Presumably this would show up as an explicit type for the third type argument for Task? Would the Roc compiler then present an error at the point where you tried to perform a disallowed task or would it error out at the point where the type was explicitly specified?
very similar to what nim has as an effect system
missed chance to mention zig :)
This looks very similar to how Parser combinators work. Parsers returning parsers.
The non-capabilities seem like capabilities to me.
Effects are specific beasts that need to be distinguished from purely functional code as much as possible.
How is map_err specifically used for Errors only? It seems to me like something like map_type is much more generic and useful.
it's basically monadic bind (your map_type), but for the error path of the code instead of success
Is IT possible to do the same Thing in Rust?
Yes it is. But I imagine it wont be as ergonomic as this because you would have to implement the Task monad manually everywhere. Most of the functional features of Rust are first class because otherwise using them is not nice. Perhaps if you could derive Task automatically with macros but I'm not a big Rust expert so I don't know.