5 ms·

That means they do meaningless unnecessary wrapping too. It is even more ridiculous for a weak-typed language. The only point of a Monad is that in a lazy lang

That means they do meaningless unnecessary wrapping too. It is even more ridiculous for a weak-typed language. The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation. The monadic code, then, could be generalized over >>=, >> and return, and given that, specialized instances of a Monad class could be made, like Maybe, ST and what not. The only meaning in performing these steps is to establish a guaranteed order of evaluation (via implicit nesting of functions) for serialized abstractions. But that is ok, most of Javascript coders never studied CS fundamentals or comparative PL.

tathougies 8y ago
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.
choeger 8y ago
> The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation. That is not true at all. You seem to confuse side-effect-free with lazy and the state monad with any monad. Monad instances like options or either data types allow for the simple composition of functions that yield them. In any language. Promises form a useful monad because there is no other way to talk about values that have not been evaluated yet.
- throwaway487549 8y ago
  > there is no other way to talk about values that have not been evaluated yet. There is a way, and it is known since at least R5RS. https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Promises.html https://www.gnu.org/software/mit-scheme/documentation/mit-sc...
still_grokking 8y ago
It's really funny to see someone complaining about the lack of CS fundamentals in other people but does not know the difference between a weakly typed language and a dynamic one. :-D To recapitulate some basics: JS is a strongly typed dynamic language.
- throwaway487549 8y ago
  > JS is a strongly typed Strongly typed implies no implicit coersions at runtime. Python is strongly typed. JS or PHP are weakly typed.
  - still_grokking 8y ago
    That's wrong. What's about this Python code: 1.0 + 1 Or this Scala Code: "1".toFloat + "1".toInt In both cases that's clearly implicit type coercion at runtime. So according to the above constraint there would hardly be any strongly typed languages… (But quite the opposite is true in fact). Weakly typed means you can hose the type-system somehow and then perform some "illegal" or completely nonsensical operation. For example that's easy in C, but not possible in JS. In a strongly typed language any value has some precise type at any time. This is true for JS so it's strongly typed.

tathougies 8y ago

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.

choeger 8y ago

> The only point of a Monad is that in a lazy language it desugars into an implicit nested functions, which guarantees the order of evaluation. That is not true at all. You seem to confuse side-effect-free with lazy and the state monad with any monad. Monad instances like options or either data types allow for the simple composition of functions that yield them. In any language. Promises form a useful monad because there is no other way to talk about values that have not been evaluated yet.

throwaway487549 8y ago
> there is no other way to talk about values that have not been evaluated yet. There is a way, and it is known since at least R5RS. https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Promises.html https://www.gnu.org/software/mit-scheme/documentation/mit-sc...

still_grokking 8y ago

It's really funny to see someone complaining about the lack of CS fundamentals in other people but does not know the difference between a weakly typed language and a dynamic one. :-D To recapitulate some basics: JS is a strongly typed dynamic language.

throwaway487549 8y ago
> JS is a strongly typed Strongly typed implies no implicit coersions at runtime. Python is strongly typed. JS or PHP are weakly typed.
- still_grokking 8y ago
  That's wrong. What's about this Python code: 1.0 + 1 Or this Scala Code: "1".toFloat + "1".toInt In both cases that's clearly implicit type coercion at runtime. So according to the above constraint there would hardly be any strongly typed languages… (But quite the opposite is true in fact). Weakly typed means you can hose the type-system somehow and then perform some "illegal" or completely nonsensical operation. For example that's easy in C, but not possible in JS. In a strongly typed language any value has some precise type at any time. This is true for JS so it's strongly typed.