4 ms·

So you think there's a construct that allows you to do what Promises do that are simpler and do not form a monad? Please, do tell. > But that is ok, most of J

So you think there's a construct that allows you to do what Promises do that are simpler and do not form a monad? Please, do tell. > But that is ok, most of Javascript coders never studied CS fundamentals or comparative PL. Can you explain what you mean by this? You seem to be under the impression that javascript the language did something extra to make Promises form a monad when in reality, the very idea of a Promise forms a monad to begin with, independent of any particular implementation in javascript.

throwaway487549 8y ago
> Promises do that are simpler and do not form a monad? Promise is just an Abstract Data Type. It does not have to be an instance of a Monad. https://docs.racket-lang.org/referenc/Delayed_Evaluation.html https://docs.racket-lang.org/referenc/Delayed_Evaluation.htm... https://docs.scala-lang.org/overviews/core/futures.html https://docs.scala-lang.org/overviews/core/futures.html Update: It so annoying to have your legitimate posts being flagged by some SJW idiots. HN became a safe-space for mediocre, intelligence-cosplaying snowflakes. Do your homework first, before flagging others.
- smadge 8y ago
  This exchange has nothing to do with social justice and the people who are disagreeing with you aren’t snowflakes. If we define snowflake as someone who reacts to something they disagree with with outrage and accusations, then it’s clear who is being a snowflake. Back to the technical topic, the point I and others are making is that yes, you are correct that Option/Maybe is “just” an algebraic data type that is the sum of a type and a terminal object called unit, None, or Nothing. However people are disagreeing with you that it’s not a monad. It mathematical must be a monad, with the same certainty that it’s an algebraic data type or defines an endofunctor from A to A + 1. You can debate the usefulness of this fact, but your comments suggest you think it is “just” an algebraic data type and it somehow doesn’t induce a function that obeys the algebraic monad laws.
- mikekchar 8y ago
  I think you will find it productive to consider that you may be wrong. Your examples are literally monads (and I use the word "literally" literally). I think the problem you are facing is that your understand of what a monad is may be incorrect (and this, in turn, may be the fault of some random bad tutorial on monads). When you are discussing things of this fashion it can be helpful to allow yourself some room to accept a view which is different than you currently hold. Otherwise it can devolve into a shouting match over who is stupider, rather than an opportunity to see things in a different way (and perhaps learn something interesting). When 2 people are arguing, the one who is right wins the argument, but the one who is wrong has the most to gain because they can learn something. By insisting on being right, you forever cut yourself off from that potential. I know you didn't ask for that advice, so if it's not appropriate for you, please feel free to file it in the round bin.
  - throwaway487549 8y ago
    May be. I think a Monad is an abstraction which generalizes a transition, similar to a step of logical deduction. It Haskell a similar concept is actually used to compose what they call actions, originally used to implement IO. Out of this particular design choice, there are some specialized instances of Monads in Haskell, including State Monad. In the context of a lazy language, like Haskell, where the order of evaluation is not defined and each expression is an implicit thunk, monadic composition is necessary and sufficient to implement serialized sequenced actions, defined as different instances of Monad type-class and to ensure, by the type checker, that these actions are of proper type (isolated from any other instances) and are properly serialized. Just this. As a consequence of being desugared into function composition with parameter passing (>>=), which is only relevant for a lazy language, there is literally no way to access the state from outside of each pair of nested functions, so things like ST or STM are implemented as Monad. All this is relevant for Haskell and irrelevant in Scala, where you don't have to compose functions to ensure order of evaluation. Algebraic data types and "semicolons" is good-enough.
    - john_courtland 8y ago
      > All this is relevant for Haskell and irrelevant in Scala, where you don't have to compose functions to ensure order of evaluation. Promises and Futures are counterexamples to your claim here.
- smadge 8y ago
  Also to follow up on your link to the documentation of promises in Scala, here is a quote: “To simplify the use of callbacks both syntactically and conceptually, Scala provides combinators such as flatMap, foreach, and filter used to compose futures in a non-blocking way.” ‘flatMap’ is exactly the bind function for the promise monad. It doesn’t have to explicitly implement some monad interface to be a monad, it just is.
  - still_grokking 8y ago
    That's not 100% correct. Something that implements a "monad interface" (e.g. has pure, map and flatMap methods) doesn't compulsorily have to be a monad. A monad has to obey the monad laws to be one. Scala's Future is not a monad per se: https://stackoverflow.com/questions/27454798/is-future-in-scala-a-monad https://stackoverflow.com/questions/27454798/is-future-in-sc...
    - smadge 8y ago
      I was assuming a pure core of Scala, its true I should have been more explicit. Arbitrary side effects and IO make it impossible to reason algebraically/equationally about your programs.
  - throwaway487549 8y ago
    To be a Monad you have to implement at least 2 functions >>=, and return, which must follow so called Monadic laws (of proper composition - associativity, etc). flatMap is just a function. One more time - Futures are orthogonal to Monads. They may be viewed as such, but it is not necessary. Having only flatMap is sufficient for a strict language.

throwaway487549 8y ago

> Promises do that are simpler and do not form a monad? Promise is just an Abstract Data Type. It does not have to be an instance of a Monad. https://docs.racket-lang.org/referenc/Delayed_Evaluation.html https://docs.racket-lang.org/referenc/Delayed_Evaluation.htm... https://docs.scala-lang.org/overviews/core/futures.html https://docs.scala-lang.org/overviews/core/futures.html Update: It so annoying to have your legitimate posts being flagged by some SJW idiots. HN became a safe-space for mediocre, intelligence-cosplaying snowflakes. Do your homework first, before flagging others.

smadge 8y ago
This exchange has nothing to do with social justice and the people who are disagreeing with you aren’t snowflakes. If we define snowflake as someone who reacts to something they disagree with with outrage and accusations, then it’s clear who is being a snowflake. Back to the technical topic, the point I and others are making is that yes, you are correct that Option/Maybe is “just” an algebraic data type that is the sum of a type and a terminal object called unit, None, or Nothing. However people are disagreeing with you that it’s not a monad. It mathematical must be a monad, with the same certainty that it’s an algebraic data type or defines an endofunctor from A to A + 1. You can debate the usefulness of this fact, but your comments suggest you think it is “just” an algebraic data type and it somehow doesn’t induce a function that obeys the algebraic monad laws.
mikekchar 8y ago
I think you will find it productive to consider that you may be wrong. Your examples are literally monads (and I use the word "literally" literally). I think the problem you are facing is that your understand of what a monad is may be incorrect (and this, in turn, may be the fault of some random bad tutorial on monads). When you are discussing things of this fashion it can be helpful to allow yourself some room to accept a view which is different than you currently hold. Otherwise it can devolve into a shouting match over who is stupider, rather than an opportunity to see things in a different way (and perhaps learn something interesting). When 2 people are arguing, the one who is right wins the argument, but the one who is wrong has the most to gain because they can learn something. By insisting on being right, you forever cut yourself off from that potential. I know you didn't ask for that advice, so if it's not appropriate for you, please feel free to file it in the round bin.
- throwaway487549 8y ago
  May be. I think a Monad is an abstraction which generalizes a transition, similar to a step of logical deduction. It Haskell a similar concept is actually used to compose what they call actions, originally used to implement IO. Out of this particular design choice, there are some specialized instances of Monads in Haskell, including State Monad. In the context of a lazy language, like Haskell, where the order of evaluation is not defined and each expression is an implicit thunk, monadic composition is necessary and sufficient to implement serialized sequenced actions, defined as different instances of Monad type-class and to ensure, by the type checker, that these actions are of proper type (isolated from any other instances) and are properly serialized. Just this. As a consequence of being desugared into function composition with parameter passing (>>=), which is only relevant for a lazy language, there is literally no way to access the state from outside of each pair of nested functions, so things like ST or STM are implemented as Monad. All this is relevant for Haskell and irrelevant in Scala, where you don't have to compose functions to ensure order of evaluation. Algebraic data types and "semicolons" is good-enough.
  - john_courtland 8y ago
    > All this is relevant for Haskell and irrelevant in Scala, where you don't have to compose functions to ensure order of evaluation. Promises and Futures are counterexamples to your claim here.
smadge 8y ago
Also to follow up on your link to the documentation of promises in Scala, here is a quote: “To simplify the use of callbacks both syntactically and conceptually, Scala provides combinators such as flatMap, foreach, and filter used to compose futures in a non-blocking way.” ‘flatMap’ is exactly the bind function for the promise monad. It doesn’t have to explicitly implement some monad interface to be a monad, it just is.
- still_grokking 8y ago
  That's not 100% correct. Something that implements a "monad interface" (e.g. has pure, map and flatMap methods) doesn't compulsorily have to be a monad. A monad has to obey the monad laws to be one. Scala's Future is not a monad per se: https://stackoverflow.com/questions/27454798/is-future-in-scala-a-monad https://stackoverflow.com/questions/27454798/is-future-in-sc...
  - smadge 8y ago
    I was assuming a pure core of Scala, its true I should have been more explicit. Arbitrary side effects and IO make it impossible to reason algebraically/equationally about your programs.
- throwaway487549 8y ago
  To be a Monad you have to implement at least 2 functions >>=, and return, which must follow so called Monadic laws (of proper composition - associativity, etc). flatMap is just a function. One more time - Futures are orthogonal to Monads. They may be viewed as such, but it is not necessary. Having only flatMap is sufficient for a strict language.