Robert Jacques wrote:
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 is completely incorrect. It can only change strength if its
signature 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.
