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? 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?
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