It is almost like you didn't read my post. They provide forkIO as a basic tool to do both. That is explicitly not different tools. They also provide addition

It is almost like you didn't read my post. They provide forkIO as a basic tool to do both. That is explicitly not different tools. They also provide additional abstractions to make different tasks easier. Tasks like parallelising sequential code, which you want to pretend is the only kind of parallelism that exists. Haskell provides different abstractions for lots of things, that doesn't mean those things require different tools. It means convenience matters. >If you're more interested in performance than non-determinism, learn about parallelism first." First, not instead of. >GHC implements some major extensions to Haskell to support concurrent and parallel programming Yep, that really sounds like they require different tools, the way the mention them together as a single topic. >GHC supports both concurrency and parallelism And does so with the same tool: forkIO. Completely contrary to your claim that haskell is evidence that it requires separate tools. This is once again made very clear on a page you link to: >Ordinary single-threaded Haskell programs will not benefit from enabling SMP parallelism alone: you must expose parallelism to the compiler. One way to do so is forking threads using Concurrent Haskell (Section 7.18.1, “Concurrent Haskell”), but the simplest mechanism for extracting parallelism from pure code is to use the par combinator They are literally saying "use a higher level abstraction instead of rolling your own directly with concurrency constructs". This is the same advice that is always given when a higher level abstraction is available. It directly contradicts the claim that parallelism requires a different tool. It explicitly states that you can do it with the same tool.