Indeed so, but that would require a few months worth of work from the reader, unfortunately.
(I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car is cdr".)
"Humor can be dissected, as a frog can, but the thing dies in the process and the innards are discouraging to any but the pure scientific mind." - E. B. White.
And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
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.
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.
even for someone moderately interested in FP, this one goes above my head and the only take-away I can get from it is "maybe use ocaml instead of haskell"
I'm reasonably versed in Haskell and my response would be that it shouldn't make that much difference to you what they've written in here. I've yet to see any code in the wild using the backpack extension.
> Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.
There is a really interesting interview with Simon Peyton-Jones referenced on HN yesterday.He talks a lot about why Haskell came about, and some of the thinking behind the design choices that were made.
That era is now over.
(I have a t-shirt with a lambda in a circle, reminiscent of the anarchist emblem, and words "no class, no state". It's definitely possible to explain to a passer-by who never studied FP what it refers to, but not in such a way that the joke remained funny. Possibly the same deal is with the bumper sticker saying "my other car is cdr".)
How often do people think you're a Half-Life fan instead?
And I wouldn't be surprised if there were more retired left handed surgeons in their 50s living in rural Switzerland than people who understand what he's talking about.
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.
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...
*: 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.
> Have you ever seen a Number grazing in the fields? Or a Functor chirping in the trees? No? That’s because they’re LIES. LIES told by the bourgeoisie to keep common folk down.
https://news.ycombinator.com/item?id=45242530
https://williamcotton.com/articles/a-burrito-is-a-monad