On 8/10/07, Michael Vanier <mvanier@cs.caltech.edu> wrote:

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).

Ah interesting :-)

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.

Erlang message passing rocks :-) I'd love to see this working in Haskell.

Note that Erlang's message passing is not perfect. Specifically, there is zero type or parameter checking. It will quite happily let the following compile:

% initialization routines etc go here
% ...

% ping thread. this sends messages to pong
ping() ->
   pong ! hello,
   pong ! hello,
   pong ! {hello},   % this does not throw a compile error
   pong ! hello,
   io:format("ping done~n" ).

% pong thread, this listens for messages from pong
pong() ->
   receive
      hello ->
         io:format("pong received hello~n"),
         pong()
   end.

You can see that sending the tuple {hello} does not cause a compile time error (or even a runtime error for that matter), even though pong does not have a valid pattern for receiving it.

Now, arguably the fact that we are pattern matching on the receiver at least means we dont do anything with the invalid data sent, but this is not rocket science: the standard technique to ensure decent compile time validation in rpc-type things is to use an interface.

The interface defines the method names and parameters that you can send across. Both the receiver and the sender have access to the interface definition, and it is trivial to check it at compile time.

(Caveat: havent looked enough into Erlang to know if there is a good reason for not using an interface?)