>>>>> "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--