How does Aff compare with the Future monad


#1

mrtnbroder [3:04 AM]
can https://github.com/slamdata/purescript-aff be compared to the Future monad?

kritzcreek [3:06 AM]
Yeah, pretty much. As long as your Future is lazy and fires once at most

mrtnbroder [3:08 AM]
is there some resource I can look at that defines all the laws a Future monad has to obey? (or the methods that define a Future monad)
I’d like to know who came up with the concept

kritzcreek [3:11 AM]
Future’s are more of a special case of Cont
the fire once restriction and baking in error handling are primarily for performance and convenience reasons
I can’t find a canonical paper, but I learned about them from the “Callback Hell” chapter in “PureScript by example” https://leanpub.com/purescript/read#leanpub-auto-callback-hell

mrtnbroder [3:17 AM]
I see

kritzcreek [3:17 AM]


that version works with the newest compiler
The laws a Future needs to obey to be a Monad are just the Monad laws

mrtnbroder [3:21 AM]
but where do some of these methods come from like fork? since a future is lazy you have to run it
i guess the terms are interchangeable fork/run

kritzcreek [3:24 AM]
well in Aff at least they are different

kritzcreek [3:26 AM]
fork and run are operations you need to be able to do concurrent programming. Future/Aff aim to be a primitive to enable concurrent programming, so that’s why they have to implement it. Nothing about Monad there.

mrtnbroder [3:27 AM]


some insight in there

mrtnbroder [13 hours ago]
how do you know that these methods are related to concurrent programming? :slightly_smiling_face: that’s what I like to know!

kritzcreek [13 hours ago]
If you want to do concurrent programming you need to be able to spawn different threads of control flow (don’t take threads to mean CPU threads here)

kritzcreek [13 hours ago]
that’s basically the definition of concurrent programming

kritzcreek [13 hours ago]
and fork is a simple primitive that allows you to do that. The other side of the coin is usually to unify two threads of control flow which is commonly called join (but that’s not the Monad join the term comes from Computer science not math)

kritzcreek [12 hours ago]
I guess I’m still not really understanding what you’d like to know/find out.

mrtnbroder [12 hours ago]
I should maybe take a look at some book about concurrent programming or something

mrtnbroder [12 hours ago]
I did not study computer science nor mathematics so I am not familiar with the base concepts behind concurrent programming (esp in haskell) so that’s maybe where the answer I am looking for lies

kritzcreek [12 hours ago]
I’d say start with the motivation

mrtnbroder [12 hours ago]
motivation for what? :wink:

mrtnbroder [12 hours ago]
I am psyched to learn more!

kritzcreek [12 hours ago]
Concurrent programming is much harder than sequential programming, so we’d better have a good reason for it

kritzcreek [12 hours ago]
and one important lesson we all learn at some point… if there’s any way to write a sequential program over a concurrent one, DO IT

kritzcreek [12 hours ago]
The introduction chapter of “Parallel and Concurrent Programming in Haskell” from Simon Marlow gives a pretty good definition of concurrency https://www.oreilly.com/library/view/parallel-and-concurrent/9781449335939/ch01.html#sec_terminology