In particular, I suggest his Haskell lectures to anyone interesting by theoretical aspects of functional programming. https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun...
I didn't quite get it the first time around, but now I get it. Good read. It is about the road from research to production, culminating in LINQ.
[1] https://scholar.google.com/scholar?cluster=17368623574878046...
Considering that his (and my) compatriots Stroustrup and Lerdorf did C++ and PHP repsectively, a national apology might sort of be in order.
Cont r a = (a -> r) -> r
I'm reading it as 'Container' passed 'r' and 'a' performs 'a' to 'r' which returns 'r'. (I'm guessing on verbs here)..
I've never come across a good way to read these type signatures.
type Cont r a = (a -> r) -> r
(a -> r) is the type of a function from a to r. For example, Int -> Bool is the type of a function from Int to Bool. (a -> r) -> r is the type of a function that takes a function from (a -> r) as its argument and returns an r. So Cont String Int takes a function from Int to String as its argument and finally returns a String.
http://www.haskellforall.com/2012/12/the-continuation-monad.... https://begriffs.com/posts/2015-06-03-haskell-continuations....
This is an equation; it's a relating/defining one thing in terms of other things. In particular, there's no concept of "performing" (e.g. there's no time, state, etc. here)
In this case "Cont" is just a name; we can tell that, since the equation tells us that "Cont r a" is equal to some other thing involving "r" and "a", so we could just as well use that other thing (that's what it means for two things to be equal!). Hence, "Cont r a" is just a shorthand for "(a -> r) -> r".
So what is "(a -> r) -> r"? In general, for any types "x" and "y", the type "x -> y" is the type of functions which take an "x" as input and return a "y".
So "a -> r" is a function which takes an "a" and returns an "r".
So "(a -> r) -> r" is a function which takes a function from "a" to "r", and returns an "r".
Cont r a is a computation that knows how to produce an "a" but, instead of returning it directly, passes it to a function that takes the "a" and produces an "r".
Compared to typical sequential execution, this gives more power to the "current" phase of the computation, because it might choose to invoke the passed a -> r function more than one time, none at all, inspect the resulting "r" and change course based on the result, etc.
How do I “prove” a type forms a monad? I only have to implement `lift` and `bind` with the correct behavior, and I have a monadic interface. Did I prove then that the type forms a monad?
> Good developers understand that they can't do everything, and they know how to leverage tools as prosthetics for their brains.
it can also become a distracting fetish.