Re: Is this a bug in my code or the compiler?

[Brad Moore <brad.moore@shaw.ca>]

On 2015-06-12 12:00 PM, Dmitry A. Kazakov wrote:
> On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote:
>
>> On 12.06.15 18:15, Dmitry A. Kazakov wrote:
>>> Foo (A) and Foo (A) -- Illegal
>>> Foo (A) and then Foo (A) -- Legal
>>
>> C has similar features...
>
> So?
>
>>> P.P.S. It would become even worse with fine-grained parallelism, as Georg
>>> keep on suggesting.
>>
>> Not sure to what this is referring
>
> Parallel evaluation of arguments.

In the above case with regard to implicit parallelism, the compiler
should be able to determine that the two calls both involve
modifications the same storage, which would be a data race, and then
rule out parallelism and thus generate sequential code. So the issue
here is not about parallelism, but about ordering of evaluation for the
sequential case.

For the sequential case, I would think that a good compiler could also
detect that an expression with multiple calls with in out parameters to
the same storage is likely a problem with evaluation order, and
generate a warning to the programmer, which could be averted by coding
with "and then" for force evaluation order. If your compiler does not
generate such a warning, it might be good to ask your vendor  to
provide such a warning.

Or a programmer could adopt a programming style to use "and then" for
the general case, which I believe could be checked by a tool such as
AdaControl.

This should work for the case Boolean sub expressions, but doesn't help 
in the case of concatenation operations. Hopefully, the compiler could
at least generate warnings for this case, then the programmer can
decide how best to address the warning.

>
>> Query-command separation (on objects) seems far better than
>> functions that make their side effects explicit.
>
> You forgot about indefinite return values, which are not available for
> procedures. The real motivation to have functions with side effects is such
> return values.
>
>> So, in Ada 83, when A is of an access type,
>
> That does not change anything because:
>
>>      Foo (A) and Foo (A)  -- Legal
>
> Only if A is a constant access. Illegal otherwise.
>
> With parallelism atomicity of all immutable operations would additionally
> be required. Which is why that sort of parallelism is a can of worms.
>
>> Moreover, if B and A become pointing to the same object,
>>
>>      Foo (A) and Foo (B)  -- Legal, same effects
>>
>> Can a compiler detect this?


In Ada 2012, we have the attributes 'Has_Same_Storage and 'Overlaps_Storage.

These were introduced to facilitate writing preconditions for a
subprogram.  One would think that if these are available for checking
multiple parameters of a subprogram, the compiler could also do similar
checks for the parameters of subprograms that are part of the same
expression. In some cases, this could be a compile time check, but in
others, it may need to be a run-time check, that possibly could be
enabled/disabled via compiler options.

Brad

>
> Easily. Access is logically a referential type which, if properly designed,
> should be a subtype of the target type. Thus the same rules would apply. If
> access is meant to be a type of its own, like a pointer in C, then the
> language should better have no such types.
>
>> --- So, you'd be asking for pure
>> functions? Or total referential transparency?
>
> Both.
>
> Though purity is not enough for parallelism. A pure function may still get
> broken under parallel access if not atomic.
>