Monads: From Web 2.0 to Hardware Drivers
well-typed.com
Monads: From Web 2.0 to Hardware Drivers
1–8 of 8 posts
Re: Monads: From Web 2.0 to Hardware Drivers
#2> 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();
};
Re: Monads: From Web 2.0 to Hardware Drivers
#3The 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.
Re: Monads: From Web 2.0 to Hardware Drivers
#4That 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.
Re: Monads: From Web 2.0 to Hardware Drivers
#5The 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…
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.
Re: Monads: From Web 2.0 to Hardware Drivers
#6The 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…
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.
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.
Re: Monads: From Web 2.0 to Hardware Drivers
#7That 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, synchronou…
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.
Re: Monads: From Web 2.0 to Hardware Drivers
#8> 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 a…
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.