Re: How to get nice with GNAT?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 26 Nov 2014 15:27:35 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:g70ue0kjz9qi$.1b2fj6sqtjbez$.dlg@40tude.net...
> ...
>> If exceptions were under a contract, the list of possible exceptions to
>> catch would be definite and quite small in most cases. So, actually, we
>> could disallow "when others" for all subprograms having an exception
>> contract and calling only such subprograms (statically).
> 
> The practical problem with exception contracts is that they encourage people 
> (especially coders rather than engineers) to "eat" exceptions rather than to 
> figure out what ought to be done with them (or better yet, redoing the 
> code/preconditions/predicates so they can't arise). That's the practical 
> experience with them in Java, and that has caused some ARG members to be 
> rather strongly against them. (Which is why they didn't make it into Ada 
> 2012.)

Right, but only if you require all subprograms to have contracts. Why
should we? We couldn't anyway because it would break backward
compatibility. Thus, IMO, there is nothing to worry about here.

> I personally find that misguided (because Ada is for engineers, not coders), 
> and I'll try again with them the next Ada amendment.

Good

> BTW, that's a problem with all statically cateogorization contracts. We're 
> looking at a potentially blocking cateogorization as part of the 
> parallelization effort. What happens there is that calling any routine that 
> is potentially blocking is illegal inside of a routine that is declared as 
> non-blocking. (And unlike exception contracts, there's no workaround). The 
> effect is that one has to change the status of lots of routines in order to 
> use the categorization.

Which is desired, isn't it?

> (At least for this particular categorization, Ada 
> already says which language-defined routines are potentially blocking, so 
> it's just a matter of putting that into aspects and pragmas as needed - no 
> arguments about whether Sin should be potentially blocking :-)

Conditionally blocking? Some predicates could depend (statically) on
expressions. This is important for exceptions as well:

   generic
      with procedure Visitor (E : Element);
   procedure Iterate (X : Container);
 
If Visitor is not contracted and Iterate is, then the contract of Iterate
should be "I raise, what Visitor does".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de