[lutusp]

> It's a red herring because the original claim was not "Haskell can compute function Java cannot" but rather "there are many libraries in Haskell which aren't even possible to write in Java".

That's false. It's as false as the other claims.

> The argument is that there are libraries you can write in Haskell that you can't write in Java.

Still false.

> Similarly, since self-modification is something a library can do, possible on one model but not another, it isn't a red-herring.

It's a red herring because libraries do not ever self-modify. Not. Ever.

> Hopefully that cleared things up a bit.

Oh, it definitely did.

[tikhonj]

False, is it? I'm quoting the opening comment directly: "There are many libraries in Haskell which aren't even possible to write in Java". So that is the initial argument. It says nothing about computable functions and everything about possible libraries.

Or do you mean the argument itself is false? Well, a library providing new control structures certainly fits that! But yes, it's as false as my other claims--not false at all.

There are Turing-complete languages where you cannot add new control structures. (Or even ones where the concept of "control structure" does not apply.) So a library providing control structures would be impossible. And Haskell has a slew of libraries for control flow: everything in the Control.* namespace.

So both languages are Turing-complete and equally powerful, and yet certain libraries can only be written in one. This only makes sense for self-referential things, where the library somehow affects the language.

As far as self modifying code goes--it's not that the library modifies itself; rather, the library gives you tools for writing self-modifying code. If your language does not have this capability, such a library could not exist. But the language would still be Turing-complete!

The post seems to have cleared up nothing. Ah well, c'est la vie.