Repository navigation
Revisit Computation Expressions design #140
Description
I'm opening this issue as a centralized place to discuss and review the current design of the generic Computation Expressions.
The main issue of the current design was highlighted by @cmeeren recently and has to do with the "autosense" design decision, to allow to figure out automatically in many trivial cases the evaluation strategy of the Computation (lazy vs strict).
We can discuss to change it, make it more explicit, or add another set of builders that are more strict and keep backwards compatibility.
Please raise all your questions, opinions, proposals, here.
Activity
wallymathieu commentedon Nov 1, 2018
I think it would make sense to add some more documentation about
MonadPlus. Perhaps something like:wallymathieu commentedon Nov 2, 2018
I've added a pull request where I've tried to fill in some of the information: #141
wallymathieu commentedon Aug 30, 2020
Any thoughts on this @cmeeren?
cmeeren commentedon Aug 30, 2020
About what? the last update I can see in this issue is from almost 2 years ago.
nikolamilekic commentedon Aug 30, 2020
I just wanted to add my two cents to this before closing #346.
I think that computation expressions should not deviate from universally understood concepts as that would surprise and confuse users (especially newbies such as myself). A try...with operation for instance should always handle exceptions and not propagate them (in other words it should behave similarly to the try...with expression outside of a computation expression). This is currently not the case for lazy monads but is the case for strict monads, and I'm hoping this discrepancy will be fixed by any future redesign.
cmeeren commentedon Aug 30, 2020
Wait, what? Are you saying that if I replaced the built-in
asyncwithmonadfrom FSharpPlus, the exception handling would be very different? That is indeed confusing (and yet another reason I'm sceptical of using the generic CEs from FSharpPlus).wallymathieu commentedon Aug 30, 2020
Perhaps in order for a redesign to happen, we need to have some idea about how what kind of design should be suitable. Since v2 is coming up we have more room for breaking changes.
wallymathieu commentedon Aug 30, 2020
From what I hear it sounds like there would be value in having more strict builders in order to avoid confusion.
gusty commentedon Aug 30, 2020
I think the issue is that try .. with has different requirements when the monad is lazy.
For a strict monad, we can use the generic try .. with which is already included and working in the
monad.strict(or simplymonad') generic computation expression.Lazy monads on the other hand can't use a generic try .. with and each type needs to provide a specific
TryWithimplementation.At the moment we have to educate the user to prevent him to write such code but ideally a workflow that is not lazy over a type that doesn't provide a
TryWithmethod should not compile and throw a compiler error stating that.I'm not sure if that's achievable, maybe if we move the generic
TryWithfrom the Monad file to the strict builders and replace them with a compiler error message will address the issue, at the cost of removing the possibility of customizing theTryWithfor strict monads.@nikolamilekic even withouth this library, try .. with is used in all common F# lazy monads, namely the built-in
seqandasync.gusty commentedon Aug 30, 2020
Actually, looking at the code, we already call a generic try with for strict builders.
So, all we have to do is to fail at compile-time in the generic TryWith
See #347