Hugh Perkins wrote:
I'm not trolling, despite strong appearances to the contrary ;-) My primary objective/goal is to find a way to make threading easy. Thread management today is like memory management in the early 90s. We kindof had tools (new, delete in C++ for example) to do it. At some point we started to use things like Smart Pointers to make it easier, but none of it really worked. Issues such as circular referential loops caused this not to work very well.
At some point, someone came out with the idea of a garbage collector, which is really very simple once you know: all it does is walk the graph of variables, starting with those we know are definitely used, and delete all those objects that didnt get walked on. Simple, easy, magic.
We should do the same thing for threads. Threading is going to become a major issue soon, maybe not tomorrow, but there is a GPL'd Niagara 2 out with 64 threads (I think?), so the time is now.
Haskell solves a huge issue with threads, which is locking, which is a total PITA in imperative languages, it's of the same order of magnitude of problem as eliminating memory leaks, without deleting something twice etc, used to be in pre-GC C++.
Just to get the history right: garbage collectors have been around a _long_ time, since the '60s in Lisp systems. They only became known to most programmers through Java (which is one unarguable good thing that Java did). As for threading, in addition to Haskell's approach you might also look at Erlang, which has a quite different (and quite interesting) approach to the whole problem. I wonder if anyone has tried to implement a message-passing style of concurrency in Haskell. Mike