Phil, thanks for the response.

> I was thinking about the dynamic behavior of par, and there's something
> that's a little confusing to me. Am I right in understanding that (x
> `par` y) evaluates to y, and may or may not evaluate x along the way?

The reason that par doesn't necessarily evaluate it's 1st argument is that
typical parallel Haskell programs contain vast amounts of potential
parallelism. So rather than create a relatively heavyweight thread and be
forced to administer it, e.g. schedule it for every possible expression
that could be evaluated in parallel, the expression is 'sparked', i.e. a
lightweight action that simply notes that the expression *could* be
evaluated in parallel.

I guess this comes down to how par is used. If par is used where evaluation would otherwise be entirely lazy, I wouldn't worry too much about reasoning about whether the sparked thread actually starts or not. But it would be nice to take code that has had seq introduced in some places to avoid stack overflows from excessive laziness and be able to replace seq with something else that would keep the same strictness, but evaluate in parallel. Of course, this could be done at a higher level than the cut-and-paste approach.

While I've got you're attention, I wonder if you could help me understand the current state of GPH, and how it relates to recently available shared-memory parallelism available in GHC. It seems to me the ease of parallelism in Haskell could be its "killer app", at least for the folks I interact with. It would be nice if the same code could be used on GPH and parallel GHC, but I'm not sure whether that's the case. Having GHC run in parallel out of the box is great, but if it's moved to a distributed-memory system, I'm also not sure to what extent increased latency is taken into account.

Thanks,

Chad Scherrer

"Time flies like an arrow; fruit flies like a banana" -- Groucho Marx