May I re-ask Jonathan’s question?

My understanding, from having read OOSC (instead of TAPL, which I hope to rectify but have not yet), is that method arguments can only be contravariant to the type hierarchy. I think you claim that Java’s type system is weak (in this instance) because it does not allow contravariant method arguments. How do functional types deal with this - it seems from my understanding - contradiction?

Yep, it’s not (necessarily) me who doesn’t understand purity

In fact, it is possible to demonstrate that the function void touch(String filename) is referentially transparent, simply by taking a stance that most audiences accept as plausible. The difference is of course, that the so-called ‘implicit’ arguments are not expressed by the function type, which leads to errors. In fact, I have yet to find a piece of software, be it the touch function or J2EE Jumping Joey’s database application, that cannot be written as a lambda expression. Maybe it is not me who does not understand purity? I can’t really refute any of your other claims, since they are simply unsupported.

Further, there is no attempt to legitimise the use of a monad type in Java - simply to point out that higher-order types exist to Java users and postulate that they might be important.

And the idea that ‘using this makes a method impure’ is so obviously wrong. Even for Java beginners. Just look at the String-class as an example. ‘this’ is simply an implicit parameter to a call, it can’t break purity more or less than any explicit parameter can. I really have ask myself, if Tony even knows the meaning of ‘pure’ in this context.

Why would you want to use a monad in Java is entirely another mystery. It is analogous to advocating the elimination of the while loop in favor of right folds. You should keep in mind that monads were always and are still a semantic concept (categories belong to the domain of semantics), not a syntactic one. That Haskell implementers found it appropriate to model (_not_ implement) sequencing, side-effecting, etc. doesn’t mean that they must be tacked onto any “imperative” problem whatsoever (whatever that is, if it is anything at all).

Without pattern matching as part of the language, the optimum case is that the object can match patterns for you - this is why my Maybe type looks like:

public interface Maybe<T>
{
<R> R apply(Lazy<R> ifNothing,Function<T,R> ifJust);
}

(not the same as the one posted earlier; this one is from real code)

Lazy has T invoke() and Function has R invoke(T).

I implement bind as a static method, and only implement it for Maybe, not for any general Monad interface, as I don’t have a meaningful abstraction for monads in general. You can consider apply as emulating pattern matching; it is the minimum and maximum required to enable all use cases of Maybe.

So it seems we have identified your mistake. Your function is indeed impure. I truly struggle to find a way of pointing this out, since it is bleedingly obvious. Perhaps a use case if you don’t see it immediately upon reflection.

Further, a curried function has nothing to do with state, but I can see how you have become confused. I still maintain that if you were to fix your code, you’d end up with my original function signature.

It is not a secret that referential transparency is a property that is relative to the observer and you have simply shifted your point of observation, into the murky waters of imperative programming. You will then freely admit that there is an additional function argument that is not expressed in your code? It is represented by ‘this’ in Java.

Passing your entire universe of discourse is guaranteed to provide referential transparency, regardless. Regress from that point and I think you’ll see your mistake.