On Wed, 22 Sep 2010 11:44:00 -0400, Don <nos...@nospam.com> wrote:
Robert Jacques wrote:
On Wed, 22 Sep 2010 07:54:26 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-09-22 01:26:01 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
So removing the concurrency safety from pure would greatly expand
the number of pure functions, however, automatic parallelism would
be lost.
Don clearly mentioned that this is not lost. Basically, for safe
parallelism what you need is a function that has a) pure and b) no
mutable reference parameter. Both are easily checkable at compile
time, you'd just need to change your test for pure for a test that
also checks the arguments.
What is lost is my ability to declare a function does x in the
signature and for the compiler to check that. I really want to know if
code monkey A changed some type's implementation to be thread unsafe,
because detecting and tracking down a loss of performance due to loss
of automatic parallelism is devilish.
No, you haven't lost that at all. Any function marked as pure still has
no access to any state, other than what is provided by its parameters.
It is still thread-safe.
No, it isn't. A strongly-pure function is thread safe, but a weakly-pure
function isn't. Since strong/weak is automatically determined by the
compiler, a function's strength can switch due to long distance code
changes. This wouldn't be an issue today, but tomorrow large strongly-pure
functions will be parallelized automatically in a manner akin to inlining
(outlining?). Then it makes a difference. However, these issues feel more
like D3 concerns than D2 concerns, particularly when you consider the
advantages of making tasks/futures a language level concept.
