Required (or at least Opt-In) stack safety for monadic types. #1520
Replies: 2 comments
-
|
I don't really have the bandwidth to get into this right now, but it's the same trampoline principle that's in the As I noted in this comment, I'm fully loaded with tasks, and dealing with this feature + replacing all of the core functionality of every monad is reeeeeeally not on my list of desires right now. I appreciate the offer of help, but this feature (which I will implement at some point), will likely be far too noisy for me to deal with. I'd definitely prefer to attack it myself once I can free up some time. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We (one of my teams) is working on a port of the Scala library "doobie" over to C#, and making heavy use of LanguageExt to even begin to make this possible.
Having said that, I was surprised to not find required (or at least opt-in) stack-safety for monads. This is required in Cats for something to be a monad, and opt-in for Scalaz, and giving that recursion is a very common pattern in FP, this seems like a sorely missing feature.
See:
FlatMapBindRecBefore I start working on a PR for this, I want to check that:
FlatMap<M>andFlatMapRec<M>type classes (a la Scalaz style), and then havingMonad<M>extendBind<M>. In this way, implementors can "opt-in" to declaring their monads "stack safe", by including implementingBindRec<M>(and library implementers can require it as a gen param constraint).BindRec<M>that (e.g.) 100,000 left/right nested binds do not blow the stack.Option,IO,Seq).Rough draft sketch:
@louthy - thoughts?
Beta Was this translation helpful? Give feedback.
All reactions