Re: Intervention needed?

["Randy Brukardt" <randy@rrsoftware.com>]

"Olivier Henley" <olivier.henley@gmail.com> wrote in message 
news:b5b45418-4773-4768-89aa-f72f22da2e6e@googlegroups.com...
On Wednesday, March 13, 2019 at 5:10:31 AM UTC-4, Maciej Sobczak wrote:
>> So, seriously - what's wrong with pointers in Rust?

>From that excerpt by Oliver Scherer (Rust compiler contributor), it looks 
>like
>the ownership aspect that comes with them is a real improvement:
>
>"The two (obviously not a good amount of datapoints) large scale 
>refactorings
>in Ada software that I've been part of have resulted in horrible hacks 
>where
>people just spammed protected and pragma everywhere to get stuff working
>and bug free. The protected injections are because it's nearly impossible 
>to
>figure out which things are accessed by multiple tasks without SPARK and
>you end up with undefined behaviour if you accidentally have a shared 
>access
>to an unprotected memory location. The pragmas were reconfiguring things
>like stack size or disabling compiler warnings without actually thinking 
>about
>what these changes meant.

Obviously, if your existing code isn't documented properly as to what needs 
to be task-safe, then refactoring it isn't going to work very well. 
Refactoring bad code is just going to give you bad code. :-) And almost all 
code in any language is bad code, because at some point people turned to 
"just make it work" mode, and stopped doing the things necessary for the 
code to be understandable. Using Ada helps, but surely doesn't eliminate 
this point.

In any case, Ada 2020 is very much about addressing this point. The new 
Nonblocking and Global contracts make is possible to declare tasking and 
memory side-effects, and the "conflict check policies" allow using that to 
prevent data races. (Note that there is a difference between a "data race", 
and "race conditions"; there are plenty of race conditions that aren't data 
races, and no programming language can statically prevent the latter, since 
they're caused of a sequence of operations. Well, other than not having any 
task interactions in the first place. :-)

In addition, conflict checks are enabled by default on the new parallel 
constructs, so you have to work at causing problems. (The parallel 
constructs are safer anyway, since they do not allow blocking, so there 
aren't any rendezvous and entry calls to worry about.) And they can be 
enabled on tasks as well (not done by default for the obvious reason of 
compatibility - but also for capability, tasks should mainly be used in Ada 
2020 when one needs rendezvous and other contructs that can't be checked at 
compile-time).

The issue with this is that a dereference of an access value is almost 
always going to cause a conflict and thus be illegal. And the contracts for 
the containers are designed so that they can be used in parallel operations 
(presuming the actual parameters to the instance allow that). This means 
that no access types can be used to implement the containers, which is 
nonsense for the unbounded and indefinite containers. The ownership stuff is 
a proposal to limit that in the case of building ADTs, including the 
containers.

                                Randy.