finally won’t work
port io.monadless._
import fs2._
import scala.concurrent._
import scala.concurrent.ExecutionContext
import language.higherKinds
trait MonadlessTask extends Monadless[Task] {
def collect[T](list: List[Task[T]]): Task[List[T]] =
Task.traverse(list)(identity).map(_.toList) //Future.sequence(list)
def rescue[T](m: Task[T])(pf: PartialFunction[Throwable, Task[T]]): Task[T] =
m.handleWith(pf) //m.recoverWith(pf)
/*
def ensure[T](m: Task[T])(f: => Unit): Task[T] = {
m.onComplete(_ => f)
m
}
*/
}
object MonadlessTask extends MonadlessTask
Hi @fwbrasil,
Thanks for creating this tool. Im quite interested in sort of the "monad syntax inversion" that Monadless provides.
I write alot of heavily monadic code, mainly using Eff and are pretty dissatisfied with for {} yield () as a syntax for monad logic.
For me, the biggest pain-point is actually verbose duplication in for expressions, between the terms on the right and the left. I seem to write an increasing number of fors that look like:
for {
a <- something.a
b <- a.b
c <- b.c
} yield cand a little voice in my head keeps nagging me whenever I grind out another of these overly-redudant structures. What I want to write is something.a!.b!.c! (where ! is basically yourunlift). Im convinced that is the future.
ATM I'm trialling @Atry's DSL but I also intend to give Monadless a try to compare.
One thing that's held me back from Monadless is the lack of a global "opt-in", as provided by the reseteverywhere plugin in DSL. When monads are 80% of your methods, having to write lift {...} everywhere will get boring.
Would you be open to considering a similar compiler plugin for Monadless?
Hi @fwbrasil
What do you envisage would trigger the implicit macros to transform the code in a method into "monadless" form?
The way DSL works is: a reseteverywhere plugin traverses all the defs and vals in the code and annotates them with a @reset annotation, which then causes a second compiler plugin to transform them to CPS style
=============== ============== ============
Re: your concern's about "too much magic": thats a reasonable, sensible concern.
However, in truth, I dont share the concern. And thats because I'm convinced this monadless representation will become very popular/influential in future programming.
if you imagine living in 1975, alot of things we do in programming, eg type inference, references instead of pointers, GC, dynamic linking, Futures, for expressions, would look like magic. But it turned out they could be made usable and predictable, and when things are useful, people will accept huge amounts of magic.
Somehow, by embracing Eff early Ive ended up writing much more pervasively monadic code than the wider population of programmers. And Ive tasted some problems that aren't yet widely recognized.
When most of your code is monadic, the economics change. The costs and limitations of our current-generation clunky monad syntax goes from annoyance to a major pain in ass. Calling a chain of methods that all return their result inside an M wrapper is much harder than it should be.
I feel like you and @Atry and @peletom (with Effectful ) have built implementations of a powerful new idiom for effectful programming, and the world hasn't "caught up" and realized how much potential it has.
In Haskell-land they are still coming to terms with this idea too.
Im curious, did you take the idea from Idris .. or another source.. or has it evolved concurrently?
