4 ms·

Monads: From Web 2.0 to Hardware Drivers

66 points by lelf 12y ago

Xophmeister 12y ago
> 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 12y ago
  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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
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 12y ago
  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.

66 points by lelf 12y ago

> 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 12y ago
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 12y ago

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 12y ago
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 12y ago
  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 12y ago

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 12y ago
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.