  In this case that’s the >>= from Maybe.Monad. As long as you satisfy the signature, it’s happy . do has nothing to do with Monads! Who lied to you?

Could have been a stronger point by using a non-monadic >>=.

I've been doing a lot of parsing lately and I find I don't need to reach all the way for monad (applicative is usually enough). But I guess that's what ApplicativeDo[1] is for.

  We’ve got to be explicit now which Functor or Monad we’re importing, and you can’t have do notation for different Monads in the same module.

This is a bit rough for usability (not to mention also undermines the point above).

But overall I like the approach of trying something radically new.

[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/appl...

▲ kccqzy a day ago | parent [-]

ApplicativeDo can be thought of as a compile-time transformation that turns sequential code into possibly parallel* code just by analyzing the way variables are used. Once I've had that realization I really appreciated it more.

*: By "possibly parallel" I mean the blocks of code are known to be independent from each other. They could be actually executed in parallel if the Applicative instance does so.

▲

ambicapter a day ago | parent [-]

Does that mean it may or may not run the code in parallel once compiled? Doesn't seem very ergonomic to the developer if true.

	▲	kccqzy a day ago \| parent [-]
		Why isn't it ergonomic? You just read the documentation or source for the Applicative class in question to find out. If the Applicative class chooses to decide randomly whether to run in parallel, that's the class's fault, not the language or the compiler's problem.