
Monads: From Web 2.0 to Hardware Drivers - lelf
http://www.well-typed.com/blog/105/
======
Xophmeister
> Functions that take a callback argument are called asynchronous functions.

Just to nit pick... Passing a callback to a function as an argument doesn't
magically make that function asynchronous, in JavaScript. For example:

    
    
        var block = function(callback) {
          while(true) {}
          callback();
        };
    

Only those functions that are implemented asynchronously (such as Node.js'
fs.readdir, from the article's example) will _actually_ be asynchronous.

~~~
echaozh
Asynchronicity doesn't necessarily mean the function will be call at a later
time. Rather it should mean the function will not be called by me at a
previously known time without knowing the implementation of the function I am
calling. Encapsulation, you know.

Using callbacks means giving up control of when things will happen. The fact
that it will actually happen very soon is out of the question.

------
olavk
The Javascript example kind of confuses the solution with the problem. The
convoluted syntax of the 'callback-hell' is the problem. Monads does not solve
this problem, rather the use of monads leads to that kind of syntax. The
solution proposed for the syntactic mess is Haskells do-notation. Do-notation
is not monads, rather it is syntactic sugar to make the use of monads
bearable. Something like lisp macros would be a more general solution to the
same problem.

~~~
mightybyte
But lisp macros don't give you the strong type safety properties that Haskell
gives you with monads. The most general solution is not always the thing you
want. Sometimes you want the solution that gives you the strongest guarantees
about the potential behavior of code.

~~~
olavk
My point is that do-notation is comparable to macros since it is a kind of
syntactic sugar. Monads on the other hand are a type (or design pattern,
depending on perspective), not a kind of syntactic sugar. So you can't compare
lisp macros to monads.

------
ksherlock
That javascript code is awful (and yet probably typical). There are three
asynchronous readdirs that don't depend on each other (and should be able to
run parallel) which now depend on each other and any asynchronous benefit is
lost. Maybe haskell is smart enough to run them in parallel. For javascript,
Promise.all would be better and avoid the pyramid of doom. Or, just use
synchronous code for your, well, synchronous code.

~~~
vampirebat
Every monadic expression needs to be "run", and it turns out that with a
different run function that exact code could be made to execute in parallel.
In practice, though, you would probably use an explicit parallel combinator.

