How side effects work in FP
chadnauseam.com
How side effects work in FP
1–10 of 107 posts
Re: How side effects work in FP
#2dweb link:
> ipfs resolve -r /ipns/nauseam.eth/coding/random/how-side-effects-work-in-fp/: no link named "coding" under QmdzzonFE9eX6FGs8UbCyoC2XS5NQjaG6gaqhgeUyTHnag
Re: How side effects work in FP
#3Haskell is a framework that takes a monad interface implementation and performs IO based on it. The monad in question is used like a self flattening iterator / generator, and together with lazy evaluation it can function like a regular program even though the monad itself is implemented using pure functions.
Re: How side effects work in FP
#4> I don't know why people try to explain monads without explaining this first
I mean, I get where you're coming from, but the thing that you've described is that a monad and there's not an easy way to get it there.
But yes, I am with you, you want to explain to someone that Haskell's model of side effects is a sort of metaprogramming, much simpler than macros, we just give you a data type for “a program which does some stuff and eventually can produce a ______” and ask you to define a value called `main` which is a program which produces nothing special. And it's the compiler's job to take that program and give it to you as a binary executable that you can run whenever you like.
You also want to give people a number of other examples of things that are monads. “a nullable ____”, “a list of ____s,” “an int (summable) with a ____,” and maybe an example that is not like “a function from ____s to ints,” or “a set of ___s.”
The key to telling someone what a monad is, involves trying to explain to them that in some sense “a program which produces a program which produces an int” is not terribly more descriptive than just “a program which produces an int.” If you can combine this with the adjective being outputtish and universal you have a monad.
Re: How side effects work in FP
#5> Equational Reasoning
Probably the best reason to use FP imo. It just cuts out so much overhead when trying to read other people’s code.
Re: How side effects work in FP
#6As someone who has never really understood monads (or tried that hard to) but who has done a good amount of Javascript programming, I really like the description of a monad as a series of nested data structures describing the next steps of a project.
Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to execute with the results.
Re: How side effects work in FP
#7As someone who has never really understood monads (or tried that hard to) but who has done a good amount of Javascript programming, I really like the description of a monad as a series of nested data structures describing the next steps of a project. Ultimately, that's very similar to what old-school ways of declaring Promises do in Javascript. You're creating a data structure that you then attach a new function to e…
Not just similar. Promises are a monad. Though they don't strictly follow the monad laws as they are collapsing in JavaScript due to how Promise.resolve never allows a promise to resolve to a promise but only to the value of a promise.
Re: How side effects work in FP
#8Well, that's the first time side effects in Haskell made sense to me. Well done.
Not that I've ever seriously tried to learn Haskell, but in the past every time I've lazily come across an article about it it's always seemed like a bizarre confusing world, even though I know how functional programming (in the sense of purity) works.
Now there's just one thing missing. We all know what this style of programming is. It's asynchronous programming with callbacks. Seriously, Haskell folks, if you started with "all side effecting functions are kind of like async operations with a completion callback (the stuff people do in JavaScript all day), and then we have some syntactic sugar to make it suck less" you'd have a much easier time getting people to wrap their head around all this.
(Yes, I know the details aren't exactly the same, but drawing parallels to stuff people already know matters)
Seriously, this idea of there being a central effect dispatcher (the bit that runs `main` behind the scenes) is so eerily like the coroutine scheduler in async coroutine paradigms that I can't believe more people haven't drawn parallels between these programming styles.
Re: How side effects work in FP
#9This is a great way to help people get an intuition for monadic IO.
Re: How side effects work in FP
#10[dead]