3 ms·

This is why I always find it sad that people are averse to learning about "abstract, impractical" concepts like monads. Monads are abstract, but they are far fr

This is why I always find it sad that people are averse to learning about "abstract, impractical" concepts like monads. Monads are abstract, but they are far from impractical: they solve problems which you are already encountering, and even already identifying as problems. The best solution would be to add monadic syntax to javascript. You would get CPS, coroutines, error propagation, early failure, and several other capabilities all using the same syntax. Shit like generators or coroutines are just ad-hoc special-cased versions.

olavk 16y ago
I would like to try to do something like that! Do you have thought about how a syntax like "do" would look in JavaScript?
- jhpriestley 16y ago
  Probably a lot like javascript. with_monad(foo){ var x = bar(); baz(x); } where foo includes a definition of bind and return (return should be renamed, there is already a return in js). Subcalls like baz(x) would be interpreted within the same monad. Basically you would just make semicolon a function with dynamic extent, rather than a language builtin. I don't know if it would be possible to monadize functions which use break, continue, or return. While and if would have to be special cased.
  - olavk 16y ago
    But wouldn't that require that all calls inside the with_monad block is of the same monad type? Wouldn't the syntax need a way of distinguishing between monadic and non-monadic operations (like using "let" rather than "<-" in Haskells do-syntax)?
swannodette 16y ago
I'm completely convinced that the growing ubiquity of asynchronous and multithreaded code will all drive us to embrace Object Oriented Programming 2.0 AKA Functional Programming. Can't come fast enough for me.
- harryh 16y ago
  I, for one, hope that you are right (though the pessimist in me is skeptical).
barrkel 16y ago
I'm not convinced that monads give the best tooling story. If you have a nice syntax for passing the operations into the monad, that means there's going to be quite an aggressive transformation of the source syntax; and since the control flow - i.e. the calling of the functions passed into the monad - is determined by the monad, it's harder to analyse at a higher level. If you have a powerful type system that's open enough to encode further guarantees in it, so that the library itself can supply higher-level proofs of properties (if not analyses that can e.g. be queried and manipulated in an IDE context), that's great; but it doesn't help in an environment like Javascript, or even Java or C#. And I'm not sure it helps in larger scale situations, e.g. debugging multiprocess interaction. With so much done in libraries, you run the risk of tools not knowing enough about the program to help. I guess what I'm saying is that the case for ad hoc special cases is quite strong outside of situations where all your programmers are highly trained and have deep knowledge of all domains intersecting with their problems.

olavk 16y ago

I would like to try to do something like that! Do you have thought about how a syntax like "do" would look in JavaScript?

jhpriestley 16y ago
Probably a lot like javascript. with_monad(foo){ var x = bar(); baz(x); } where foo includes a definition of bind and return (return should be renamed, there is already a return in js). Subcalls like baz(x) would be interpreted within the same monad. Basically you would just make semicolon a function with dynamic extent, rather than a language builtin. I don't know if it would be possible to monadize functions which use break, continue, or return. While and if would have to be special cased.
- olavk 16y ago
  But wouldn't that require that all calls inside the with_monad block is of the same monad type? Wouldn't the syntax need a way of distinguishing between monadic and non-monadic operations (like using "let" rather than "<-" in Haskells do-syntax)?

swannodette 16y ago

I'm completely convinced that the growing ubiquity of asynchronous and multithreaded code will all drive us to embrace Object Oriented Programming 2.0 AKA Functional Programming. Can't come fast enough for me.

harryh 16y ago
I, for one, hope that you are right (though the pessimist in me is skeptical).

barrkel 16y ago

I'm not convinced that monads give the best tooling story. If you have a nice syntax for passing the operations into the monad, that means there's going to be quite an aggressive transformation of the source syntax; and since the control flow - i.e. the calling of the functions passed into the monad - is determined by the monad, it's harder to analyse at a higher level. If you have a powerful type system that's open enough to encode further guarantees in it, so that the library itself can supply higher-level proofs of properties (if not analyses that can e.g. be queried and manipulated in an IDE context), that's great; but it doesn't help in an environment like Javascript, or even Java or C#. And I'm not sure it helps in larger scale situations, e.g. debugging multiprocess interaction. With so much done in libraries, you run the risk of tools not knowing enough about the program to help. I guess what I'm saying is that the case for ad hoc special cases is quite strong outside of situations where all your programmers are highly trained and have deep knowledge of all domains intersecting with their problems.