From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA13289 for caml-red; Fri, 15 Dec 2000 13:50:21 +0100 (MET) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA10504 for ; Thu, 14 Dec 2000 20:07:38 +0100 (MET) Received: from lavoro.home.cs.york.ac.uk (caldo.demon.co.uk [194.222.207.148]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id eBEJ7aL25084 for ; Thu, 14 Dec 2000 20:07:37 +0100 (MET) Message-Id: <200012141907.eBEJ7aL25084@concorde.inria.fr> To: caml-list@inria.fr Subject: Re: callcc/cps-style programming Date: Thu, 14 Dec 2000 19:08:04 0000 From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr Ousterhout's paper on the dangers of threading was remarkable for failing even to mention years of research by Hoare and Milner (amongst others) into much better ways of programming concurrent applications than either 1960s style wait/notify style or 1970s monitors. occam, Erlang and others applied the new techniques quite successfully. Of course, the whole point of developing the techniques was to address the problems listed in Ousterhout's paper! >>Period. But user-level threads, implemented in the language, don't >>give you much value. Much better to do some sort of explicit (perhaps >>semi-automated) CPS-conversion, and use an event-dispatcher. One reason for using them (and concurrent programming) is simpler and clearer programs than the rats' nest that often results from call backs and other attempts to emulate proper processes.