🚀 go-pugleaf

This article is in two parts, both are questions, the former being more of
a discussion.

In <1992Aug14.155639.1045@EE.Surrey.Ac.UK> Roger Peel writes:
Parallel
enhancements to a sequential language might be acceptable for particularly
large-grained parallel tasks, too, but this is not where occam stands out,
either.

In article <rob.714140217@dutncp8> rob@pact.nl (Rob Kurver) writes:
Such function calls don't
provide the necessary level of abstraction for fine-grain parallelism,
and often cause an unacceptable overhead.

In what way isn't occam good at large-grained parallelism?
Is the due to the machinery that has to be built to set up a pipeline,
geometric distribution or a processor farm?
The first two can be built simply, though without a great deal of efficiency.

Though there is an equivalent weakness in the data structure side of
programming languages.  Linked lists and binary trees are effectively large
grain data structures and we have to continually build and re-build those.

Rob again:
This allows fine-grain parallelism to be expressed just as easily as in Occam.

Does it have the compilation checks too?

>Best,

>Rob

Warren