On Nov 27, 2005, at 2:36 PM, Bill Wood wrote:
(I'm going to do a lazy permute on your stream of consciousness;
hope it
terminates :-).
I think the Rubicon here is the step from one to many -- one
function/procedure to many, one thread to many, one processor to
many, ... . Our favorite pure
Hello Greg,
Saturday, November 26, 2005, 8:25:38 PM, you wrote:
GW Maybe this is a different topic, but exploring concurrency in Haskell
GW is definitely on my to do list, but this is really a bit of a puzzle.
GW One thing I've been thinking lately is that in functional programming
GW the
Hello jerzy,
Sunday, November 27, 2005, 3:49:07 PM, you wrote:
for pure functional computations concurrency is just one of
IMPLEMENTATION mechanisms, and it doesn't appear in abstractions
DEFINITIONS
jkiuf Well, there are formal aspects of the specification of concurrency as
well.
jkiuf Do
--- Bulat Ziganshin [EMAIL PROTECTED] wrote:
Hello Greg,
for pure functional computations concurrency is just one of
IMPLEMENTATION mechanisms, and it doesn't appear in abstractions
DEFINITIONS
I suppose it depends a bit on the question you're asking. A
multiprocessor, considered as a
(I'm going to do a lazy permute on your stream of consciousness; hope it
terminates :-).
I think the Rubicon here is the step from one to many -- one
function/procedure to many, one thread to many, one processor to
many, ... . Our favorite pure functions are like the Hoare triples and
Dijkstra
