>>54
right, some mathematican invented that shitty name and some other shitheads thought it was a good idea to rename old concepts (encapsulation) in programming with it, instead of using a name which describes what monads are good for. I wonder why some people try so hard to find creative names, which fit the topic.
>>56
>Except it's not a function being executed N times and having side effects, it's a function being composed against itself to the Nth degree and having cumulative effects on a value invisibly threaded through the whole sequence.
Which sounds good for me, as long as nobody wants to tell me now about how we put the world state into the monad or need to compute an actual value in haskell itself besides executing the function to give it some unique id. Last problem for me in haskell solved, i should be happy.
As far as i understand it now is, that the haskell compiler can't look into the functions written in c and thus does not know what they will return with which input value, thus the created program has to execute them every time. Monads and similar stuff (Arrows) just make sure, that we use a return value only one time.
Only problem is a runtime environment, which could predict from the last input values the output values of a function and replace its call with the result without executing anything.