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
(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 we
--- 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
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.
jk
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 p
