Hacker News Reader

Comment by throwaway487549 | Hacker News Reader

This is exactly what is called "unnecessary wrapping". There is no meaning in wrapping anything into a Monad in a strict language, where the order of evaluation is well-defined, narcissistic snowflakery aside.

In other words, a Monad in the context of CS or PL is the solution to a problem which does not arise in Scala.

And, of course, an option type does not have to be a Maybe Monad, like any other Either Of type.

View on HN

I’m having trouble understanding what you mean by an option type that is not a monad.

I thought the value of an option type was being able to “program the semicolon” to do automatic null checks for you.

Option type is just an algebraic data type.

    datatype 'a option = None | Some of 'a

Which is awfully similar to Haskell's Maybe. Ignoring boilerplate and comments, the entire module is just [0]:

  data Maybe a = Nothing | Just a
    deriving ( Eq, Ord )

And the deriving line isn't really nessasary.

The Monad module is larger and contains code specific to Maybe [1]:

  instance  Monad Maybe  where
    (Just x) >>= k      = k x
    Nothing  >>= _      = Nothing
    (>>) = (*>)
    fail _              = Nothing

(Only the first 2 lines are needed. The 3rd is an optimization, the 4th is a historical wart that will be removed in future versions (moved to MonadFail)

[0] https://hackage.haskell.org/package/base-4.12.0.0/docs/src/G...

[1] https://hackage.haskell.org/package/base-4.12.0.0/docs/src/G...

And this is meaningful only in the context of a lazy language.

In the context of strict, statically typed language an algebraic Option type is good-enough.

Maybe is an algebraic Option type. It just happens to implement an interface that abstracts away the if(None) checks that you would be doing anyway. Lazyness has nothing to do with it.

The option monad is literally isomorphic to maybe. It 100% follows the definition of a monad and is an instance of the monad type class in Cats and Scalaz.

Many algebraic data types are monads. I’m not sure why you think that is a contradiction.

This isomorphism has no meaning. It is also isomorphic to logical OR, if you wish. Shall we wrap OR into a Monad?

I think you're overthinking it. The isomorphism simply exists. And you don't wrap things into a monad, you just write an instance for it -- it has no effect on the data type itself, it simply allows to use the data type in monadic contexts.

I think you mean of Either. Either is isomorphic to logical OR in type theory.

Yes, and that algebraic data type you defined is a monad, whether you acknowledge and use that fact or not.

Hmm... Javascript pervasively uses monads, in the form of promises and the await/async keywords, but it is a strict language.

If we wanted to be picky, promises technically aren't monads because .then() does too much with auto unwrapping nested promises.

https://stackoverflow.com/a/50173415 has some good examples.

It's close, though. Really close. And don't get me wrong - I still love promises and async / await. They're much better than what we had before.

That post is misguided for so many reasons. In order to say something 'forms a monad', you need to define over what operations. That poster assumes Promise forms a monad using regular javascript function composition as the function composition operator. This is stated without justification, and there are other notions of javascript function composition which would preserve the functor composition law.

More clearly, Promise indeed forms a functor, if the domain is the set of Javascript functions which do not return 'Promise<X>'.

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.

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.

> 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.

> 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-sc...

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.

> JS is a strongly typed

Strongly typed implies no implicit coersions at runtime. Python is strongly typed. JS or PHP are weakly typed.

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.

Reply on news.ycombinator.com