I’m far from convinced that I really understand this the way I should.
If so, please kindly direct me the right way.
For a while, I’ve internally thought of the Effect monad as being a sort of black-box version of the State Monad. Instead of threading around and updating some state, you pass around an opaque token representing the world (“magically” given to you at the entry point of a program).
Any time it’s even remotely possible that the outside world has changed this is represented as a new equally opaque token, with the catch being that using an “outdated” token is forbidden or undefined or some-such. This models each new token as a sort of general discreet undefined step in computation/time/changing outside world. Hens using monads to model an order of evaluation.
Looking at the implementation now though, it looks like the effect monad doesn’t really carry that extra baggage. Ie. What I described above isn’t what’s actually happening in the program. It looks like the effect monad is really just an annotation? It’s computation strategy/programmable semi-colon is similar to the identity monad, but by the name we understand that some impure shenanigans is possible.
Am I reading this properly?
data Effect :: Type -> Type main :: Effect Unit
main returns a function that, when run (what’s the input type? Doesn’t matter?) produces
unit. I don’t see bind doing anything with the input. So a Purescript program creates a single function that ultimately ignores it’s input and produces nothing. The effect type basically annotates to us that what it has actually done is (maybe) create some side effect(s).