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 PAA06585 for caml-red; Mon, 18 Dec 2000 15:45:15 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA22570 for <caml-list@pauillac.inria.fr>; Sat, 16 Dec 2000 00:13:05 +0100 (MET)
Received: from igw8.watson.ibm.com (igw8.watson.ibm.com [198.81.209.20])
	by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eBFND4X27326
	for <caml-list@inria.fr>; Sat, 16 Dec 2000 00:13:04 +0100 (MET)
Received: from sp1n189at0.watson.ibm.com (sp1n189at0.watson.ibm.com [9.2.104.62])
	by igw8.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id SAA08328;
	Fri, 15 Dec 2000 18:11:47 -0500
Received: from bismarck-chet.watson.ibm.com ([9.95.46.140]) by sp1n189at0.watson.ibm.com (8.9.3/Feb-20-98) with ESMTP id SAA18498; Fri, 15 Dec 2000 18:11:46 -0500
Received: from bismarck (bismarck.chet.org [127.0.0.1])
	by bismarck-chet.watson.ibm.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA13137;
	Fri, 15 Dec 2000 18:10:35 -0500
Message-Id: <200012152310.SAA13137@bismarck-chet.watson.ibm.com>
X-Authentication-Warning: bismarck.chet.org: Host bismarck.chet.org [127.0.0.1] claimed to be bismarck
To: Julian Assange <proff@iq.org>
cc: Chet Murthy <chet@watson.ibm.com>, Dave Berry <dave@kal.com>,
        STARYNKEVITCH Basile <Basile.Starynkevitch@cea.fr>, caml-list@inria.fr
Subject: Re: callcc/cps-style programming 
In-Reply-To: Your message of "16 Dec 2000 05:37:56 +1100."
             <wxd7etediz.fsf@suburbia.net> 
References: <3145774E67D8D111BE6E00C0DF418B6638D1D3@nt.kal.com> <200012131636.LAA02306@bismarck-chet.watson.ibm.com>  <wxd7etediz.fsf@suburbia.net> 
Date: Fri, 15 Dec 2000 18:10:35 -0500
From: Chet Murthy <chet@watson.ibm.com>
Sender: weis@pauillac.inria.fr


>>>>> "JA" == Julian Assange <proff@iq.org> writes:

    JA> Chet Murthy <chet@watson.ibm.com> writes:

    >> Stuff like:
    >> 
    >> (i) allocating memory in the middle of a finalizer -- e.g., a
    >> finalizer which is pushing some reusable resource onto some
    >> stack (and the stack needs to be grown)
    >> 
    >> (ii) locking some object in a finalizer, which can also be
    >> locked by some thread that which would allocate memory with
    >> that lock held.
    >> 
    >> (iii) SMP-unsafe code galore -- race conditions,
    >> memory-incoherence, thrash-prone code.

    JA> If code is written in a functional manner, almost all of these
    JA> problems disappear. This is why functional languages and
    JA> concurrency dovetail so nicely together. Further, in some
    JA> cases you can use concurrency to hide state changes; allowing
    JA> one to write functional code where previously it was unatural
    JA> to do so.

The sorts of code I described cannot be written functionally.  It
talks to the outside world, or pools resources (and no, the GC isn't
perfect, so you _do_ have to pool resoruces from time to time), or
does any of a number of other things that make it necessary to use
shared variables.

I'm an old ML programmer.  I've written lots and lots of ML code
(including what I believe was the first thread-safe SUNRPC stack -- in
SML/NJ).  But quite simply, there are things that can only be done in
a imperative manner.  Or that can only be done with shared variables.

--chet--