On Tue, 09 Sep 2008 07:33:24 Bruce Eckel wrote:
I know that both Haskell and Erlang only allow separated memory spaces with message passing between processes, and they seem to be able to solve a large range of problems -- but are there problems that they cannot solve? I recently listened to an interview with Simon Peyton-Jones where he seemed to suggest that this newsgroup might be a helpful place to answer such questions. Thanks for any insights -- it would be especially useful if I can point to some kind of proof one way or another.
In Haskell it is simply irrelevant whether parts of the structures being passed between threads are shared or not because the structures are immutable. We keep our code side-effect free and as a result it is incredibly easy to make parallel. This is so solid that we can also add implicit threading to the code with simple annotations such as 'par' and 'seq'. Having said this, it is possible to generate structures which are mutable and only accessible in the IO monad. As a general rule, IO code using shared memory has the same threading issues as in any other language while pure code is guaranteed safe. Haskell is capable of working with both models, but mutable data structures are deliberately restricted in their use and are rare in practice. A great deal of parallelism can be added to pure code without any risk. I can't assist with mathematical proofs, but can't think of any reason why shared, manipulable memory would be absolutely necessary. In the worst case, all operations on the data structure can be converted to messages to a central thread which manages that structure and serialises access. Any procedure call can become an asynchronous pair of request, response messages. I am not a mathematician, I can't prove it, but I can't think of circumstances where I would need to put mutable references in a data structure except where the language and compiler can't handle immutable structures efficiently. Tim