throwaway487549

I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream.

I would love to have ML/Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions.

Actuall, the more of ML a strict language gets in - the better.

What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity.

Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk.

It is better to lean towards ML instead of heading towards Javascript.

Yes, it was really good read, thank you. I hope I could write as clearly.

Look, however, at the use of "is" in my comment and yours. You are applying "is" to some abstract, nonexistent categories, categorizing abstractions and naming the resulting categories. I use "is" to describe what is going on, particularly in Haskell and Scala.

The whole abstract hierarchy I regard no more meaningful as hierarchy of chakras in crya yoga texts or similar sectarian pseudo-logical but disconnected from reality teachings.

While I really appreciate that you have mastered this abstract hierarchy and could in clear and precise language explain it (which is what a mathematician supposed to do) I personally refuse to take statements like "any abstract datatype is a monad" seriously.

It is a plain type-error. You are trying to say that a triangle is a number. The correct and precise way is to say "could be viewed as", because you are literally superimpose one abstraction upon another, or view one through another, if you wish.

All these nested generalizations could be superimposed on programming, but it is fundamentally wrong to say that something in programming "is" one of these abstractions.

You are speaking like a mathematician, I am speaking like a non- (or rather anti-) Plato-Hegelian philosopher.

Promises and futures in Scala standard library and in Akka have nothing to do with Monads.

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.

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

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.

> JS is a strongly typed

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

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.

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

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.

Option type is just an algebraic data type.

    datatype 'a option = None | Some of 'a