Version 1.10 of ai05s/ai05-0290-1.txt

Unformatted version of ai05s/ai05-0290-1.txt version 1.10
Other versions for file ai05s/ai05-0290-1.txt

!standard 2.8(3)          12-03-19 AI05-0290-1/07
!standard 2.8(4)
!standard 3.2.4(0)
!standard 3.8.1(21)
!standard 4.6(51/2)
!standard 4.6(57)
!standard 4.9.1(4)
!standard 6.1.1(0)
!standard 7.3.2(0)
!standard 11.4.2(6/2)
!standard 11.4.2(7/2)
!standard 11.4.2(9/2)
!standard 11.4.2(10/2)
!standard 11.4.2(16/2)
!standard 11.4.2(17/2)
!standard 11.4.2(18/2)
!standard 11.5(7.2/2)
!standard 11.5(25)
!class Amendment 12-02-14
!status Amendment 2012 12-02-14
!status ARG Approved (Letter Ballot) 11-0-2 12-03-12
!status work item 12-02-14
!status received 11-11-21
!priority Medium
!difficulty Medium
!subject Improved control over assertions
!summary
The pragma Assertion_Policy is expanded to allow control of assertion expressions in a way that is very similar to pragma Suppress, but without the possible consequence of erroneous execution.
A perceived problem with Pragma Suppress for inlined calls is fixed.
Variant parts now handle not-covered-by-any-choice selector values in the same way as case statements and case expressions.
The definition of "statically compatible" for subtypes is improved so that a type with a disabled predicate check is not statically compatible with a type with an enabled predicate check.
!problem
When assertions (particularly predicates and preconditions) are used in 3rd party libraries of packages (which can also describe reusable code used within an organization, and implementation-defined packages), additional control over the assertions is needed.
In particular, assertions used to control inbound correctness checks should (almost) never be turned off, as these are needed to prevent failures in the the implementation of the library. In particular, clients should be discouraged from turning these checks off.
However, assertions used to make internal correctness checks (such as postconditions and invariants) are less important - actions of the client should not be able to cause these to fail.
Hence, there needs to be fine control over the checks of various kinds of assertions. Control for any but the Assert Pragma cannot be sensibly based on a policy in effect at the point of the check. For example, this would cause invariant checks to be performed only occasionally. The proposal is generally that the policy in effect at the time of the aspect specification controls all its checks. A key distinction between suppressing a check and ignoring an assertion (by specifying a policy of "Ignore") is that in the latter case, the assertion expressions that are not evaluated because of the policy are not assumed to be true.
!proposal
(See wording.)
!wording
Modify 2.8(3-4) as follows:
pragma_argument_association ::= [pragma_argument_identifier =>] name | [pragma_argument_identifier =>] expression
{ | pragma_argument_aspect_mark => name
| pragma_argument_aspect_mark => expression }
In a pragma, any pragma_argument_associations without a pragma_argument_identifier {or pragma_argument_aspect_mark} shall precede any associations with a pragma_argument_identifier {or pragma_argument_aspect_mark}.
-------------
Add after 3.2.4(6/3):
Predicate checks are defined to be enabled or disabled for a given subtype as follows:
* If a subtype is declared by a type_declaration or subtype_declaration that includes a predicate specification, then:
- if performing checks is required by the Static_Predicate assertion
policy (see 11.4.2) and the declaration includes a Static_Predicate specification, then predicate checks are enabled for the subtype;
- if performing checks is required by the Dynamic_Predicate assertion
policy (see 11.4.2) and the declaration includes a Dynamic_Predicate specification, then predicate checks are enabled for the subtype;
- otherwise, predicate checks are disabled for the subtype [redundant:
, regardless of whether predicate checking is enabled for any other subtypes mentioned in the declaration];
* If a subtype is defined by a derived type declaration that does not include a predicate specification, then predicate checks are enabled for the subtype if and only if predicate checks are enabled for at least one of the parent subtype and the progenitor subtypes;
* If a subtype is created by a subtype_indication other than in one of the previous cases, then predicate checks are enabled for the subtype if and only if predicate checks are enabled for the subtype denoted by the subtype_mark;
* Otherwise, predicate checks are disabled for the given subtype.
[AARM: In this case, no predicate specifications can apply to the subtype and so it doesn't typically matter whether predicate checks are enabled. This rule does make a difference, however, when determining whether predicate checks are enabled for another type when this type is one of multiple progenitors. See the "derived type declaration" wording above.]
Replace 3.2.4(22/3) with:
If predicate checks are enabled for a given subtype, then:
In 3.2.4(23/3), replace "check is made" by "check is performed" (three times).
-------------
Add after 3.8.1(21):
When an object of a discriminated type T is initialized by default, Constraint_Error is raised if no discrete_choice_list of any variant of a variant_part of T covers the value of the discriminant that governs the variant_part. When a variant_part appears in the component_list of another variant V, this test is only applied if the value of the discriminant governing V is covered by the discrete_choice_list of V.
AARM implementation note:
This is not a "check"; it cannot be suppressed. However, in most cases it is not necessary to generate any code to raise this exception. A test is needed (and can fail) in the case where the discriminant subtype has a Static_Predicate specified, it also has predicate checking disabled, and the discriminant governs a variant_part which lacks a "when others" choice.
The test also could fail for a static discriminant subtype with range checking suppressed and the discriminant governs a variant_part which lacks a "when others" choice. But execution is erroneous if a range check that would have failed is suppressed (see 11.5), so an implementation does not have to generate code to check this case. (An unchecked failed predicate does not cause erroneous execution, so the test is required in that case.)
Like the checks associated with a per-object constraint, this test is not made during the elaboration of a subtype_indication.
End AARM Implementation Note.
-------------
Replace 4.6(51/3) with:
After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. If the target subtype excludes null, then a check is performed that the value is not null. If predicate checks are enabled for the target subtype (see 3.2.4), a check is performed that the predicate of the target subtype is satisfied for the value.
-------------
Modify 4.6(57/3):
If an Accessibility_Check fails, Program_Error is raised. {If a predicate check fails, Assertions.Assertion_Error is raised.} Any other check associated with a conversion raises Constraint_Error if it fails.
-------------
Replace 4.9.1(10/3) with:
both subtypes are static, every value that satisfies the predicate of S1 also satisfies the predicate of S2, and it is not the case that both types each have at least one applicable predicate specification, predicate checks are enabled (see 11.4.2) for S2, and predicate checks are not enabled for S1.
-------------
Replace 6.1.1(19/3) with:
If performing checks is required by the Pre, Pre'Class, Post, or Post'Class assertion policies (see 11.4.2) in effect at the point of a corresponding aspect specification applicable to a given subprogram or entry, then the respective precondition or postcondition expressions are considered @i(enabled).
AARM Note: If a class-wide precondition or postcondition expression is enabled, it remains enabled when inherited by an overriding subprogram, even if the policy in effect is Ignore for the inheriting subprogram.
Replace 6.1.1(31/3) with:
Upon a call of the subprogram or entry, after evaluating any actual parameters, precondition checks are performed as follows:
Modify 6.1.1(32/3):
The specific precondition check begins with the evaluation of the specific precondition expression that applies to the subprogram or entry{, if it is enabled}; if the expression evaluates to False, Assertions.Assertion_Error is raised{; if the expression is not enabled, the check succeeds}.
Modify 6.1.1(33/3):
The class-wide precondition check begins with the evaluation of any {enabled} class-wide precondition expressions that apply to the subprogram or entry. If and only if all the class-wide precondition expressions evaluate to False, Assertions.Assertion_Error is raised.
AARM Ramification: Class-wide precondition checks are performed for all appropriate calls, but only enabled precondition expressions are evaluated. Thus, the check would be trivial if no precondition expressions are enabled.
Modify 6.1.1(35/3):
[If the assertion policy in effect at the point of a subprogram or entry declaration is Check, then upon]{Upon} successful return from a call of the subprogram or entry, prior to copying back any by-copy in out or out parameters, the postcondition check is performed. This consists of the evaluation of [the]{any enabled} specific and class-wide postcondition expressions that apply to the subprogram or entry. If any of the postcondition expressions evaluate to False, then Assertions.Assertion_Error is raised. The postcondition expressions are evaluated in an arbitrary order, and if any postcondition expression evaluates to False, it is not specified whether any other postcondition expressions are evaluated. The postcondition check, and any constraint {or predicate} checks associated with [copying back] in out or out parameters are performed in an arbitrary order.
Delete 6.1.1(40/3).
-------------
Modify 7.3.2(9/3):
If one or more invariant expressions apply to a type T[, and the assertion policy (see 11.4.2) at the point of the partial view declaration for T is Check,] then an invariant check is performed at the following places, on the specified object(s):
Add before 7.3.2(21/3):
If performing checks is required by the Invariant or Invariant'Class assertion policies (see 11.4.2) in effect at the point of corresponding aspect specification applicable to a given type, then the respective invariant expression is considered @i(enabled).
AARM Note: If a class-wide invariant expression is enabled for a type, it remains enabled when inherited by descendants of that type, even if the policy in effect is Ignore for the inheriting type.
Modify 7.3.2(21/3):
The invariant check consists of the evaluation of each {enabled} invariant expression that applies to T, on each of the objects specified above. If any of these evaluate to False, Assertions.Assertion_Error is raised at the point of the object initialization, conversion, or call. If a given call requires more than one evaluation of an invariant expression, either for multiple objects of a single type or for multiple types with invariants, the evaluations are performed in an arbitrary order, and if one of them evaluates to False, it is not specified whether the others are evaluated. Any invariant check is performed prior to copying back any by-copy in out or out parameters. Invariant checks, any postcondition check, and any constraint or predicate checks associated with in out or out parameters are performed in an arbitrary order.
Delete 7.3.2(23/3).
-------------
Replace 11.4.2(5/2 - 7/2) with:
The form of a pragma Assertion_Policy is as follows:
pragma Assertion_Policy(policy_identifier); pragma Assertion_Policy(@i(assertion)_aspect_mark => policy_identifier
{, @i(assertion)_aspect_mark => policy_identifier});
A pragma Assertion_Policy is allowed only immediately within a declarative_part, immediately within a package_specification, or as a configuration pragma.
-----
Replace 11.4.2(9/2) with:
The @i(assertion)_aspect_mark of a pragma Assertion_Policy shall be one of Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post, Post'Class, Type_Invariant, Type_Invariant'Class, or some implementation defined aspect_mark. The policy_identifier shall be either Check, Ignore, or some implementation-defined identifier.
[AARM: Implementation defined: Implementation-defined policy_identifiers and assertion_aspect_marks allowed in a pragma Assertion_Policy.]
------ Replace 11.4.2(10/2) with:
A pragma Assertion_Policy determines for each assertion aspect named in the pragma_argument_associations whether assertions of the given aspect are to be enforced by a run-time check. The policy_identifier Check requires that assertion expressions of the given aspect be checked that they evaluate to True at the points specified for the given aspect; the policy_identifier Ignore requires that the assertion expression not be evaluated at these points, and the run-time checks not be performed. @Redundant[Note that for subtype predicate aspects (see 3.2.4), even when the applicable Assertion_Policy is Ignore, the predicate will still be evaluated as part of membership tests and Valid attribute_references, and if static, will still have an effect on loop iteration over the subtype, and the selection of case_alternatives and variant_alternatives.]
If no assertion_aspect_marks are specified in the pragma, the specified policy applies to all assertion aspects.
A pragma Assertion_Policy applies to the named assertion aspects in a specific region, and applies to all assertion expressions specified in that region. A pragma Assertion_Policy given in a declarative_part or immediately within a package_specification applies from the place of the pragma to the end of the innermost enclosing declarative region. The region for a pragma Assertion_Policy given as a configuration pragma is the declarative region for the entire compilation unit (or units) to which it applies.
If a pragma Assertion_Policy applies to a generic_instantiation, then the pragma Assertion_Policy applies to the entire instance.
AARM note: This means that an Assertion_Policy pragma that occurs in a scope enclosing the declaration of a generic unit but not also enclosing the declaration of a given instance of that generic unit will not apply to assertion expressions occurring within the given instance.
If multiple Assertion_Policy pragmas apply to a given construct for a given assertion aspect, the assertion policy is determined by the one in the innermost enclosing region of a pragma Assertion_Policy specifying a policy for the assertion aspect. If no such Assertion_Policy pragma exists, the policy is implementation defined.
[AARM: Implementation defined: The default assertion policy.]
----------
Modify 11.4.2(16/2):
A compilation unit containing a {check for an assertion (including a }pragma Assert{)} has a semantic dependence on the Assertions library unit.
[Needed because all such checks raise Assertions.Assertion_Error.]
----------
Delete 11.4.2(17/2).
----------
Replace 11.4.2(18/2) with:
If performing checks is required by the Assert assertion policy in effect at the place of a pragma Assert, the elaboration of the pragma consists of evaluating the boolean expression, and if the result is False, evaluating the Message argument, if any, and raising the exception Assertions.Assertion_Error, with a message if the Message argument is provided.
----------
Replace 11.5(7.2/3) with:
If a checking pragma applies to a generic_instantiation, then the checking pragma also applies to the entire instance.
AARM note: This means that a Suppress pragma that occurs in a scope enclosing the declaration of a generic unit but not also enclosing the declaration of a given instance of that generic unit will not apply to constructs within the given instance.
[Note: The inline part of this rule was deleted as part of these discussions.]
------------
Replace 11.5(25) with:
All_Checks
Represents the union of all checks; suppressing All_Checks suppresses all checks other than those associated with assertions. In addition, an implementation is allowed (but not required) to behave as if a pragma Assertion_Policy(Ignore) applies to any region to which pragma Suppress(All_Checks) applies.
AARM Discussion: We don't want to say that assertions are suppressed, because we don't want the potential failure of an assertion to cause erroneous execution (see below). Thus they are excluded from the suppression part of the above rule and then handled with an implicit Ignore policy.
!discussion
In order to achieve the intended effect that library writers stay in control over the enforcement of pre- and postconditions as well as type invariants, the policy control needs to extend over all uses of the respective types and subprograms. The place of usage is irrelevant. This is enforced by the rules in the !wording.
For Assert pragmas, the policy in effect for the place of the pragma is the controlling policy.
For subtype predicates, the policy that is relevant is the one in effect at the point where the "nearest" applicable predicate specification is provided.
The Assertion_Policy pragma allows control over each assertion aspect individually, if so desired. The need was clearly identified, e.g., to ensure enforcement of preconditions, while postconditions might be left to the whims of the library user.
The regions to which Assertion_policy pragmas apply can be nested (as in the library example). The simple rule is that "inner" pragmas have precedence over "outer" pragmas for any given assertion aspect.
Implementation-defined policies and assertion aspects are allowed in order that compiler vendors can experiment with more elaborate schemes.
A clear separation was made between language checks that, if failing but suppressed, render the program erroneous, and assertions, for which suppression does not cause language issues that lead to erroneousness. This is one of the reasons why assertion control was not subsumed under the pragmas Suppress and Unsuppress with appropriate check names. For example, in verified code, the policy Ignore for Assertions make sense without impacting the program semantics. (Suppressing a range check on the other hand can lead to abnormal values.)
The ARG felt the following capability to be very useful, but shied away from extending the model so late in the production if the 2012 standard. Ada 2020 should consider this capability (AI12-0022-1 has been opened to do this):
Example: Imagine the following routine in GUI library:
procedure Show_Window (Window : in out Root_Window); -- Shows the window. -- Raises Not_Valid_Error if Window is not valid.
We would like to be able to use a predicate to check the comment. With an "On_Failure" aspect we could do this without changing the semantics:
subtype Valid_Root_Window is Root_Window with Dynamic_Predicate => Is_Valid (Valid_Root_Window), On_Failure => Not_Valid_Error;
procedure Show_Window (Window : in out Valid_Root_Window); -- Shows the window.
If we didn't have the "On_Failure" aspect here, using the predicate as a precondition in lieu of a condition explicitly checked by the code would change the exception raised on this failure to be Assertion_Error. This would obviously not be acceptable for existing packages and too limiting for future packages. For upward compatibility, similar considerations apply to preconditions, so the "On_Failure" aspect is needed for them as well. We could also imagine that after one On_Failure aspect has been specified, additional preconditions could be defined for the same subprogram with distinct On_Failure aspects specifying distinct expressions to be raised.
-----
For pragma Inline (and for Assertion_Policy), we decided to eliminate the rule that said that the presence of a pragma Suppress or Unsuppress at the point of a call would affect the code inside the called body, if pragma Inline applies to the body. Given that inlining is merely advice, and is not supposed to have any significant semantic effect, having it affect the presence or absence of checks in the body, whether or not it is actually inlined, seemed unwise. Furthermore, in many Ada compilers, the decision to inline may be made very late, so if the rule is instead interpreted as only having an effect if the body is in fact inlined, it is still a problem, because the decision to inline may be made after the decision is made whether to insert or omit checks.
----
This example illustrates the motivation for the new 3.8.1 rule about variant parts:
declare pragma Assertion_Policy (Ignore);
subtype Non_Zero is Integer with Static_Predicate => Non_Zero /= 0;
type Rec (D : Non_Zero) is record case D is when Integer'First .. -1 => ...; when 1 .. Integer'Last => ....; end case; end record;
Zero : Integer := Ident_Int (0);
subtype Zero_Sub is Rec (D => Zero); -- no exception is raised here
X : Rec (D => Zero); -- raises Constraint_Error begin null; end;
We could require that a subtype declaration such as Zero_Sub fail a runtime check, but this seemed similar to per-object constraint checking.
!corrigendum 2.8(3)
Replace the paragraph:
pragma_argument_association ::= [pragma_argument_identifier =>] name | [pragma_argument_identifier =>] expression
by:
pragma_argument_association ::= [pragma_argument_identifier =>] name | [pragma_argument_identifier =>] expression | pragma_argument_aspect_mark => name | pragma_argument_aspect_mark => expression
!corrigendum 2.8(4)
Replace the paragraph:
In a pragma, any pragma_argument_associations without a pragma_argument_identifier shall precede any associations with a pragma_argument_identifier.
by:
In a pragma, any pragma_argument_associations without a pragma_argument_identifier or pragma_argument_aspect_mark shall precede any associations with a pragma_argument_identifier or pragma_argument_aspect_mark.
!corrigendum 3.2.4(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 3.8.1(21)
Insert after the paragraph:
A record value contains the values of the components of a particular variant only if the value of the discriminant governing the variant is covered by the discrete_choice_list of the variant. This rule applies in turn to any further variant that is, itself, included in the component_list of the given variant.
the new paragraph:
When an object of a discriminated type T is initialized by default, Constraint_Error is raised if no discrete_choice_list of any variant of a variant_part of T covers the value of the discriminant that governs the variant_part. When a variant_part appears in the component_list of another variant V, this test is only applied if the value of the discriminant governing V is covered by the discrete_choice_list of V.
!corrigendum 4.6(51/2)
Replace the paragraph:
After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. If the target subtype excludes null, then a check is made that the value is not null.
by:
After conversion of the value to the target type, if the target subtype is constrained, a check is performed that the value satisfies this constraint. If the target subtype excludes null, then a check is made that the value is not null. If predicate checks are enabled for the target subtype (see 3.2.4), a check is performed that the predicate of the target subtype is satisfied for the value.
!corrigendum 4.6(57)
Replace the paragraph:
If an Accessibility_Check fails, Program_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails.
by:
If an Accessibility_Check fails, Program_Error is raised. If a predicate check fails, Assertions.Assertion_Error is raised. Any other check associated with a conversion raises Constraint_Error if it fails.
!corrigendum 4.9.1(4)
Replace the paragraph:
A constraint is statically compatible with a scalar subtype if it statically matches the constraint of the subtype, or if both are static and the constraint is compatible with the subtype. A constraint is statically compatible with an access or composite subtype if it statically matches the constraint of the subtype, or if the subtype is unconstrained. One subtype is statically compatible with a second subtype if the constraint of the first is statically compatible with the second subtype.
by:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 6.1.1(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 7.3.2(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 11.4.2(6/2)
Replace the paragraph:
pragma Assertion_Policy(policy_identifier);
by:

pragma Assertion_Policy(policy_identifier); pragma Assertion_Policy( assertion_aspect_mark => policy_identifier {, @iassertion_
aspect_mark => policy_identifier});
!corrigendum 11.4.2(7/2)
Replace the paragraph:
A pragma Assertion_Policy is a configuration pragma.
by:
A pragma Assertion_Policy is allowed only immediately within a declarative_part, immediately within a package_specification, or as a configuration pragma.
!corrigendum 11.4.2(9/2)
Replace the paragraph:
The policy_identifier of a pragma Assertion_Policy shall be either Check, Ignore, or an implementation-defined identifier.
by:
The assertion_aspect_mark of a pragma Assertion_Policy shall be one of Assert, Static_Predicate, Dynamic_Predicate, Pre, Pre'Class, Post, Post'Class, Type_Invariant, Type_Invariant'Class, or some implementation defined aspect_mark. The policy_identifier shall be either Check, Ignore, or some implementation-defined identifier.
!corrigendum 11.4.2(10/2)
Replace the paragraph:
A pragma Assertion_Policy is a configuration pragma that specifies the assertion policy in effect for the compilation units to which it applies. Different policies may apply to different compilation units within the same partition. The default assertion policy is implementation-defined.
by:
A pragma Assertion_Policy determines for each assertion aspect named in the pragma_argument_associations whether assertions of the given aspect are to be enforced by a run-time check. The policy_identifier Check requires that assertion expressions of the given aspect be checked that they evaluate to True at the points specified for the given aspect; the policy_identifier Ignore requires that the assertion expression not be evaluated at these points, and the run-time checks not be performed. Note that for subtype predicate aspects (see 3.2.4), even when the applicable Assertion_Policy is Ignore, the predicate will still be evaluated as part of membership tests and Valid attribute_references, and if static, will still have an effect on loop iteration over the subtype, and the selection of case_statement_alternatives and variants.
If no assertion_aspect_marks are specified in the pragma, the specified policy applies to all assertion aspects.
A pragma Assertion_Policy applies to the named assertion aspects in a specific region, and applies to all assertion expressions specified in that region. A pragma Assertion_Policy given in a declarative_part or immediately within a package_specification applies from the place of the pragma to the end of the innermost enclosing declarative region. The region for a pragma Assertion_Policy given as a configuration pragma is the declarative region for the entire compilation unit (or units) to which it applies.
If a pragma Assertion_Policy applies to a generic_instantiation, then the pragma Assertion_Policy applies to the entire instance.
If multiple Assertion_Policy pragmas apply to a given construct for a given assertion aspect, the assertion policy is determined by the one in the innermost enclosing region of a pragma Assertion_Policy specifying a policy for the assertion aspect. If no such Assertion_Policy pragma exists, the policy is implementation defined.
!corrigendum 11.4.2(16/2)
Replace the paragraph:
A compilation unit containing a pragma Assert has a semantic dependence on the Assertions library unit.
by:
A compilation unit containing a check for an assertion (including a pragma Assert) has a semantic dependence on the Assertions library unit.
!corrignedum 11.4.2(17/2)
Delete the paragraph:
The assertion policy that applies to a generic unit also applies to all its instances.
!corrignedum 11.4.2(18/2)
Replace the paragraph:
An assertion policy specifies how a pragma Assert is interpreted by the implementation. If the assertion policy is Ignore at the point of a pragma Assert, the pragma is ignored. If the assertion policy is Check at the point of a pragma Assert, the elaboration of the pragma consists of evaluating the boolean expression, and if the result is False, evaluating the Message argument, if any, and raising the exception Assertions.Assertion_Error, with a message if the Message argument is provided.
by:
If performing checks is required by the Assert assertion policy in effect at the place of a pragma Assert, the elaboration of the pragma consists of evaluating the boolean expression, and if the result is False, evaluating the Message argument, if any, and raising the exception Assertions.Assertion_Error, with a message if the Message argument is provided.
!corrigendum 11.5(7.2/2)
Replace the paragraph:
If a checking pragma applies to a generic instantiation, then the checking pragma also applies to the instance. If a checking pragma applies to a call to a subprogram that has a pragma Inline applied to it, then the checking pragma also applies to the inlined subprogram body.
by:
If a checking pragma applies to a generic_instantiation, then the checking pragma also applies to the entire instance.
!corrigendum 11.5(25)
Replace the paragraph:
All_Checks
Represents the union of all checks; suppressing All_Checks suppresses all checks.
by:
All_Checks
Represents the union of all checks; suppressing All_Checks suppresses all checks other than those associated with assertions. In addition, an implementation is allowed (but not required) to behave as if a pragma Assertion_Policy(Ignore) applies to any region to which pragma Suppress(All_Checks) applies.
!ACATS Test
Create ACATS C-Tests to test these changes, specifically that Ignore really ignores the check and local Check policies override more global Ignore policies.
!ASIS
** TBD: Some change to pragma processing probably will be needed to account for the 'Class possibility in aspect_marks.
!appendix

From: Randy Brukardt
Sent: Monday, November 21, 2011  5:13 PM

Let me start by saying that it is awfully late for any significant change, my
default position is no change at this point, and the following issue isn't that
critical to get right. But I'd like to discuss it some and either feel better
about our current decision or possibly consider some alternatives.

----

John remarked in his latest ARG draft:

>> *** I really think that this should raise Constraint_Error and that
>> subtype predicates should not be controlled by Assertion_Policy but
>> by Suppress. Ah well.....

My initial response was:

> I agree with this. The problem is that you want to replace constraints with
> (static) predicates, but you can't really do that because people are used to
> removing assertions even though they would never remove a constraint
> check.

But upon thinking about it further, it's not that clear-cut. First, it would be
odd for static and dynamic predicates to raise different exceptions. Second,
there really isn't that much difference in use between predicates and
preconditions (entering calls) and invariants and postconditions (after calls).
So there is an argument that they all should be the same. (But of course you can
make the same arguments for constraints in both of the positions.)

The thing that really bothers me is that contracts somehow seem less important
than constraints, even though their purposes are the same. While assertions
(including the "body postconditions" we discussed a few weeks ago) really are in
a different category of importance. So it seems weird to me to include pragma
Assert and the precondition and predicate aspects in the same bucket as far are
suppression/ignoring is concerned.

Let me give an example from Claw to illustrate my point.

Most Claw routines have requirements on the some or all of the parameters
passed. For instance, Show is defined as:

       procedure Show (Window : in Root_Window_Type;
                       How : in Claw.Codes.Show_Window_Type := Claw.Codes.Show_Normal);
        -- Show Window according to How.
        -- Raises:
        --      Not_Valid_Error if Window does not have a valid (Windows) window.
        --      Windows_Error if Windows returns an error.

The implementation of Show will start something like:

       procedure Show (Window : in Root_Window_Type;
                       How : in Claw.Codes.Show_Window_Type := Claw.Codes.Show_Normal) is
       begin
           if not Is_Valid (Window) then
               raise Not_Valid_Error;
           end if;
           -- Assume Window is valid in the following code.
           ...
       end Show;

This is of course Ada 95 code (assuming no implementation-defined extensions).
So we couldn't have used pragma Assert. But even if it had existed, I don't
think we would have used it because we consider the validity check as an
important part of the contract and would not want it turned off. In particular,
the body of Show will take no precautions against Window being invalid, and if
violated, almost anything could happen. (Especially if checks are also
suppressed; note that the Claw documentation says that compiling Claw with
checks suppressed is not supported.)

Essentially, this could be incorrect without the check, and as such it is not
appropriate to use an assertion (which is supposed to be able to be ignored) to
make the check.

If I was writing this code in Ada 2012, I would want to use a predicate or
precondition to make this requirement more formal (and executable and visible to
tools and all of those other good things).

For instance, using a predicate: (I'm using a precondition mainly because it is
easier to write here; I'd probably use a predicate in practice because almost
all of the Claw routines need this contract and it would be a pain to repeat it
hundreds of times. But the same principles apply either way.)

       procedure Show (Window : in Root_Window_Type;
                       How : in Claw.Codes.Show_Window_Type := Claw.Codes.Show_Normal)
        with Pre => Is_Valid (Window);
        -- Show Window according to How.
        -- Raises:
        --      Windows_Error if Windows returns an error.

We'd prefer to remove the check from the body:

       procedure Show (Window : in Root_Window_Type;
                       How : in Claw.Codes.Show_Window_Type := Claw.Codes.Show_Normal) is
       begin
           -- Assume Window is valid in the following code.
           ...
       end Show;

But note now that the body is incorrect if the Assertion_Policy is Ignore and
the Window really is invalid. This is a bad thing: it means that code is at risk
of being used in a way that has not be tested and is not supported. (Obviously,
in this case the results aren't quite as bad in that the results aren't
safety-critical. But what about a subpool-supporting storage pool? These are
defined with a precondition:
        with Pre'Class => Pool_of_Subpool(Subpool) = Pool'Access;
and I'd expect a user-written pool to do very bad things if this is not true.
I'd surely not expect such a pool to repeat this check, but it would be
necessary to be defensive.)

To see this even more clearly, imagine that the containers library had
implemented most of its exceptional cases as predicates or preconditions. The
body of the containers may not even be implemented in Ada (GNAT for instance
suppresses checks as a matter of course in the predefined packages); if those
cases aren't checked, it is hard to predict what might happen.

Possibly important aside: I was wrong when I said the writing the condition as a
precondition or predicate didn't matter. For a precondition, the declaration of
the call determines what Assertion_Policy is in effect. Thus, extending the
existing Claw rule to include "compiling Claw with the Assertion_Policy to be
other than Check is not supported" would be sufficient to eliminate the problem
(at least formally - not so sure that is true practically).

For predicates, however, it is the Assertion_Policy in effect at the point of
the evaluation (subtype conversion, etc.) that determines whether the check is
made. That means that predicates can be ignored even if all of Claw is compiled
with Assertion_Policy = Check -- which makes the protections even weaker (since
I don't think a library should be dictating how a client compiles their code).

End possibly important aside.

Fundamentally, contract aspects are more like constraints than they are like
assertions. So it is dubious to put them into the same bucket with them. I know
at one point Tucker argued that making contracts "suppressed" rather than
"ignored" was bad because it could mean that adding contracts could make a
program less-safe. And I agree with that, except that the problem exists anyway
because the body of a subprogram with contracts is going to assume that those
contracts are true -- and the failure of that assumption is going to make the
results unpredictable. (Maybe not to the level of erroneousness, but at least in
any formal sense. And if combined with Suppress as in GNAT, we will really will
have erroneousness.)

I think it is just as bad to require a bullet-proof library to repeat all of the
predicate and precondition checks in the body "just-in-case" someone turns them
off. People hate redundant code for good reason (it gets out of sync; it makes
programs larger, it's often dead and thus causes problems with coverage
analysis, etc.)

---

If we accept the premise that assertions are different than contracts, what can
we do?

Going all the way to Suppression semantics is probably going too far, for a
number of reasons. Most importantly, if this is not combined with Suppress of
constraint checks, the code is likely to malfunction logically, but not in Ada
terms. (It's likely to fail raising a predefined exception in some unexpected
way; a manageable error.)

The most logical solution would be to have a separate Contract_Policy. Such a
policy would not include assertions (of any stripe) but would include all of the
contract aspects. (And Assertion_Policy would revert to only handling
assertions.) With such a separate policy, turning it off could be treated
similarly to suppressing checks (something only to be done in very restricted
circumstances for critical [and clearly demonstrated] needs). More importantly,
management can clearly see if it is being abused and set appropriate limits.

A less disruptive solution (from the user's perspective, it would require more
rewording in the Standard than the former) would be to have an additional
Assertion_Policy "Check_Contracts_and_Ignore_Others", which would do exactly
what it says. One would hope that if such a policy existed that the use of the
full "Ignore" could be discouraged just like the use of Suppress is discouraged.

---

I've written enough on this topic. I've been uncomfortable since thinking about
the implications of turning off these things on the storage pools and in
containers more than a year ago. But I've never been convinced in my own mind
that there is significant problem here -- and I'm still not. But noting that
John has some similar concerns, I thought it would be good to air these out.

Now it's your turn to comment.

****************************************************************

From: Tucker Taft
Sent: Monday, November 21, 2011  5:48 PM

I could see adding another policy which distinguished assertions from other
contract-like things. On the other hand, some folks (e.g. us) currently use
assertions exactly like preconditions, postconditions, constraints, invariants,
etc., so those of us already using assertions heavily probably don't see the
point.  If an assertion is violated, then bad things can happen.  You don't
generally get erroneousness, because the built-in constraint checks prevent
that.  But you can certainly get complete garbage-out, given enough garbage-in.

As far as where the policy is relevant, I am surprised that for predicates it
depends on where the check is performed. I would expect all checks associated
with the predicate on a formal parameter would be on or off depending on the
policy at the point where the subprogram spec is compiled, just like
preconditions and postconditions. Certainly you want to know when you compile a
body whether you can rely on the predicates associated with the formal
parameters, otherwise you *will* get into the erroneousness world if the
compiler makes the wrong assumption.

****************************************************************

From: Randy Brukardt
Sent: Monday, November 21, 2011  7:17 PM

> I could see adding another policy which distinguished assertions from
> other contract-like things.
> On the other hand, some folks (e.g. us) currently use assertions
> exactly like preconditions, postconditions, constraints, invariants,
> etc., so those of us already using assertions heavily probably don't
> see the point.  If an assertion is violated, then bad things can
> happen.  You don't generally get erroneousness, because the built-in
> constraint checks prevent that.  But you can certainly get complete
> garbage-out, given enough garbage-in.

My view of assertions is a bit different: an assertion is something that ought
to be True at a given point, but it doesn't affect the correctness of the
program. IMHO, checks that do affect the correctness of the program should not
be given as an assertion (pragma Assert), but rather be directly part of the
program. For instance, if you have an if statement that handles two possible
cases, but other cases are not handled, there ought to be some else branch with
a bug box or exception raise in it -- not some assertion that can be ignored.
(I've yet to see a case where a pragma Assert could do something that you
couldn't do with regular code; that's not true of our old Condcomp facility,
which allows conditionally compiled declarations and pragmas.) Thus, pragma
Assert is purely a debugging aid; it never has an affect on any sort of
correctness and it can be ignored without any harmful effects.

I realize that pragma Assert can be used in other ways than I outlined above,
but I always thought that the above was the intent -- it would surely be the way
that I'd use it (if we had implemented it at all; we have not done so to date,
so I've never actually used it).

This difference is probably why I view the other contracty things differently,
because they surely aren't optional, are not just debugging aids, and shouldn't
be ignored without lots of careful consideration. Thus lumping them together
doesn't make much sense.

I'd be happier if there was an extra policy; but I won't scream to much since
impl-def policies are allowed (so I can always define something sensible).

> As far as where the policy is relevant, I am surprised that for
> predicates it depends on where the check is performed.
> I would expect all checks associated with the predicate on a formal
> parameter would be on or off depending on the policy at the point
> where the subprogram spec is compiled, just like preconditions and
> postconditions.
> Certainly you want to know when you compile a body whether you can
> rely on the predicates associated with the formal parameters,
> otherwise you *will* get into the erroneousness world if the compiler
> makes the wrong assumption.

I had that thought as well when I noticed that difference. The problem is that
predicates belong to the subtype, not the subprogram. I could imagine a similar
rule to subprograms where the policy that matters is that which applies to the
subtype -- but that wouldn't necessarily give you certainty over the calls
(especially when the subtype and subprogram are declared in different packages).

A rule that made subtype conversions to formal parameters work differently than
other subtype conversions is just too weird to contemplate.

In any case, it does seem like there is a bug in the handling of subtype
predicates compared to the other contracts. I suppose I shouldn't be surprised;
Bob wrote the wording of predicates without considering how the other contracts
worked, while the other three were pretty much developed together.

Aside: We made whether pre and post-conditions checks are made for a dispatching
call unspecified if the call and the invoked subprogram have different policies.
We didn't do anything similar for type invariants; I would think that we ought
to (the same problems apply). [I noticed this checking to see if the rules for
type invariants were the same as for pre- and post-conditions; they are except
for this difference.]

P.S. I should stop thinking about this stuff. All I seem to find is problems.
:-)

****************************************************************

From: Bob Duff
Sent: Monday, November 21, 2011  7:35 PM

> Let me start by saying that it is awfully late for any significant
> change, my default position is no change at this point, ...

Agreed.

I don't think this stuff is very important.  There are all sorts of levels of
checking ("policies") one might want (all-checks-on, checks-suppressed,
checks-ignored, preconditions checked but not postconditions, etc).
Implementations will provide those as needed or requested by customers.  The
only important one for the Standard to require is all-checks-on.

Terminology:  I use "assertion" to refer to any sort of checks, including
pre/post-conditions.  Not just pragma Assert.  I think that matches Eiffel
terminology.

And Constraint_Error vs. Assertion_Failure is a non-issue.
A bug is a bug.

****************************************************************

From: Tucker Taft
Sent: Monday, November 21, 2011  8:41 PM

> ... Aside: We made whether pre and post-conditions checks are made for
> a dispatching call unspecified if the call and the invoked subprogram
> have different policies....

Your description seems a bit off.  It is always based on where the declaration
of some subprogram appears; the unspecified part is whether it is determined by
the named subprogram or the invoked subprogram.  It has nothing to do with where
the call is.  That is good because when compiling the body of a subprogram, the
compiler knows which rule it is following.  If it depended on where the call
was, the compiler would have no idea whether to assume the precondition has been
checked.

> ... We didn't do anything similar for type invariants; I would think
> that we ought to (the same problems apply). [I noticed this checking
> to see if the rules for type invariants were the same as for pre- and
> post-conditions; they are except for this difference.]

Yes, I would agree we need to do roughly the same thing for invariants, or pick
one, e.g., always base it on which subprogram body is invoked.

I think predicate checks associated with parameter associations really need to
be determined based on where the subprogram is declared (either the named
subprogram or the invoked subprogram).  Otherwise it is hopeless for the
compiler to take any advantage of the predicate checks.

****************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, November 22, 2011  2:50 AM

> Let me start by saying that it is awfully late for any significant
> change, my default position is no change at this point, and the
> following issue isn't that critical to get right. But I'd like to
> discuss it some and either feel better about our current decision or
> possibly consider some alternatives.
>
> ----
>
> John remarked in his latest ARG draft:
>
>>> *** I really think that this should raise Constraint_Error and that
>>> subtype predicates should not be controlled by Assertion_Policy but
>>> by Suppress. Ah well.....
>
[...] discussion deleted

> Now it's your turn to comment.

You convinced me - maybe more than you would like ;-)

I think that if we want to do it right, we need a special suppress, and a
special exception: Contract_Error. That's really what it is about.

The really important question is: is it too late in the game? We the ARG are
very carefull about meeting our deadlines. But the message I heard from NBs and
WG9 is "we are not so much in a hurry, we can accept a delay if it really
improves the language".  So it might be worth considering.

****************************************************************

From: Tucker Taft
Sent: Tuesday, November 22, 2011  7:11 AM

I think it could be a mistake to make such a strong distinction between pragma
Assert and these other kinds of assertions.  I realize that some people have not
been using assertions at all. But for those who have, they serve very much the
same purpose as these new contracts.  They are essentially higher-level
constraint checks. To imply that somehow they are fundamentally different seems
like an unjustifiable leap.

And I suppose if you don't use pragma Assert, then you really shouldn't care.

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, November 22, 2011  12:23 PM

Thinking more about future users...:

What I would like to be able to is to turn off Assertions and Postconditions in
MY code, because I have verified it to my heart's content. But what I would like
to continue checking is the Preconditions of services that my library offers.
After all, there is no limit to the s... of people (not reading contracts) and I
want to ensure that my code works as advertised.

Unfortunately, it looks like it is an all-or-nothing policy that is provided
today. If that issue is (re)opened, I would argue for the differentiation above.

If it is not re-opened then I want to note for 2020 that the upward
incompatibility of billions and billions of lines of code relying on turning off
precondition checks exists - and it would be a good thing to cause that
incompatibility ;-)

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 22, 2011  1:01 PM

> What I would like to be able to is to turn off Assertions and
> Postconditions in MY code, because I have verified it to my heart's
> content. But what I would like to continue checking is the
> Preconditions of services that my library offers.
> After all, there is no limit to the s... of people (not reading
> contracts) and I want to ensure that my code works as advertised.

I was thinking about that this morning. Propagating "Assertion_Error" from the
body of some routine indicates a bug in that routine, pure and simple. But
propagating it from a call indicates a bug in *your* code. It would be valuable
to have such a distinction -- not all code is written by the same user. (Note:
you need to include predicates with preconditions above.)

I'm thinking about something like Claw, where the failure of a postcondition or
invariant means that there is a bug in Claw (call tech support!) while the
failure of a precondition or predicate means that there is a bug in the client's
code (damn, better go fix it). There ought to be some differentiation between
these.

> Unfortunately, it looks like it is an all-or-nothing policy that is
> provided today. If that issue is (re)opened, I would argue for the
> differentiation above.

Well, what I think we see is that there are quite a few differentiations that
makes sense (contracts vs. pure debugging code [assertions]); caller vs. callee
bugs. Which is probably why we punted.

Hopefully, compiler optimizations of contracts will be good enough that
management can treat Assertion_Policy(Ignore) the same as it treats
Suppress(All_Checks) -- it needs reams of justification. (Note that in "correct"
code, most of the preconditions and postconditions will match up, so turning off
one or the other will have almost no effect on the code performance, since the
compiler will only check one anyway.)

> If it is not re-opened then I want to note for 2020 that the upward
> incompatibility of billions and billions of lines of code relying on
> turning off precondition checks exists - and it would be a good thing
> to cause that incompatibility ;-)

Agreed. Any code that *relies* on turning off checks (of any kind) is broken.
There might in very rare cases be a reason to write intentionally broken code,
but it should not be considered portable in any sense.

****************************************************************

From: Tucker Taft
Sent: Tuesday, November 22, 2011  2:19 PM

Assertion_Policy is based on compilations (typically a source file), so perhaps
you could use Ignore in the body, while using Check on the spec.

I could imagine a version of Assertion_Policy which allowed you to specify a
different exception is to be raised.  Now go talk to your favorite compiler
vendor, and don't forget to bring some cash... ;-)

****************************************************************

From: Bob Duff
Sent: Tuesday, November 22, 2011  2:38 PM

> I could imagine a version of Assertion_Policy which allowed you to
> specify a different exception is to be raised.  Now go talk to your
> favorite compiler vendor, and don't forget to bring some cash... ;-)

I agree.  I can think of all sorts of useful variations on the idea of "remove
some assertions/checks for efficiency". Given that we're not all in agreement
about what we want, the appropriate thing is to let vendors experiment, based on
customer feedback, and maybe standardize something for Ada 2020.

The Ada 2012 rules should be left alone at this point.

By the way, have any of the people participating in this discussion looked at
Meyer's Eiffel book?  He gives a set of options for turning on/off checks, with
rationale. I don't agree with everything he says, but I think we should all look
at it before trying to reinvent that wheel.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 22, 2011  1:25 PM

...
> But for those who have, they serve very much the same purpose as these
> new contracts.  They are essentially higher-level constraint checks.

That's an abuse of the construct, IMHO.

> To imply that somehow they are fundamentally different seems like an
> unjustifiable leap.

They *are* fundamentally different:
(1) As pragmas, they should never have an effect on the dynamic correctness of
    the program. It should always be possible to erase all of the pragmas and
    get a functioning program. Anything else is an abuse of pragmas. We got rid
    of almost all of the offending pragmas in Ada 2012.
(2) I've always viewed its purpose as holding code that eases debugging without
    having any effect on correctness. My programs have a lot of such code, and
    it makes sense to remove it from the production code. It makes sense for the
    Ada language to have a feature aimed at providing supporting such uses. It
    does *not* make sense to remove checks that protect the server from clueless
    clients (that's especially true in the case where the writer of the "server"
    (library) is different from the writer of the client -- exactly the case
    where Ada has better support than other languages). As such, it doesn't make
    sense for the language to support such a feature. (In the rare case where a
    check has to be removed for performance reasons, the good old comment symbol
    will suffice -- such things should *never* be done globally).

I can see Erhard's point that invariants and postconditions are fundamentally
similar (they verify the promises to the client and internally to the server,
neither of which is much interest to the client), but preconditions and
predicates are very different: they detect client mistakes -- something that is
totally out of the hands of the library creator.

> And I suppose if you don't use pragma Assert, then you really
> shouldn't care.

I would use it (as outlined above) if it had been defined in Ada 95. But I
wouldn't use it for inbound contract checks, because those should never be
turned off and I don't want to mix requirements on the client with internal
self-checks -- these are wildly different things. (Personally, I'd never want to
even use the same exception for such things, but that can't really be helped for
language-defined checks -- Constraint_Error has a similar problem of confusing
client contract checks vs. body errors.)

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 22, 2011  1:35 PM

...
> I think predicate checks associated with parameter associations really
> need to be determined based on where the subprogram is declared
> (either the named subprogram or the invoked subprogram).  Otherwise it
> is hopeless for the compiler to take any advantage of the predicate
> checks.

You'd have to propose a rule in order to convince me about this. A predicate is
a property of a subtype, and it can get checked in a lot of contexts that have
nothing to do with a subprogram call. Having different rules for subprogram
calls from other things (like type conversions, aggregate components, etc.)
would add a lot of implementation complexity, possibility for user confusion,
and wording complexity for little gain.

I could easily imagine making the rule that it is the state at the declaration
of the subtype that controls whether the check is made or not. That would mean
whether the check is made or not is not context dependent (and it would be more
like the other checks). And I think that would be enough for the compiler to be
able to make assumptions about whether the call is checked, as the subtype is
necessarily visible and previously compiled when the body is compiled (so the
compiler will know whether checks are on or off for the predicate at that
point).

Note that I think whether Type_Invariants are on or off should depend on the
type declaration, and not on the subprograms (they're necessarily in the same
package, so it would be very unusual for them to have a different state). That
would make the most sense since a Type_Invariant is a property of a (private)
type; it's odd for some unrelated declaration to be determining anything about
such a property. As noted above, the compiler would always know when the body is
compiled, and I think that is sufficient for it to make optimizations.

****************************************************************

From: Bob Duff
Sent: Tuesday, November 22, 2011  3:17 PM

> I would use it (as outlined above) if it had been defined in Ada 95.
> But I wouldn't use it for inbound contract checks, because those
> should never be
                                                       ^^^^^^^^^^^^^^^^^^
> turned off and I don't want to mix requirements on the client with
> internal self-checks -- these are wildly different things.

I agree with the distinction you make between internal self-checks in a library
versus checks on clients' proper use of that library.

But I think it's very wrong to say "should never be turned off"
about ANY checks.  If I have strong evidence (from testing, code reviews,
independent proof tools, ...) that calls to the library won't fail
preconditions, and I need to turn them off to meet my performance goals, then I
want to be able to do so. CLAW is not such a case, because it's not
performance-critical, because it's painting stuff on a screen.  But you can't
generalize from that to all libraries.

Commenting them out is not a good option, because then I can't automatically
turn them back on for debug/test builds.

Look at it another way:  The ability to turn off checks (of whatever
sort) gives me the freedom to put in useful checks without worrying about how
inefficient they are.  I've written some pretty complicated assertions, on
occasion.

Or yet another way:  The decision to turn checks on or off properly belongs to
the programmer, not to us language designers.

Erhard imagines a library carefully written by competent people, and a client
sloppily written by nincompoops.  That is indeed a common case, but the opposite
case, and everything in between, can also happen.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 22, 2011  4:23 PM

> Assertion_Policy is based on compilations (typically a source file),
> so perhaps you could use Ignore in the body, while using Check on the
> spec.
>
> I could imagine a version of Assertion_Policy which allowed you to
> specify a different exception is to be raised.  Now go talk to your
> favorite compiler vendor, and don't forget to bring some cash... ;-)

My favorite vendor needs more time to do the work as opposed to cash. :-)
[Although I suppose cash to live on would help provide that time...probably
ought to go buy some lottery tickets. :-)]

I agree that vendor extensions here will be important (some sort of function
classification to allow optimizations will be vital). I do worry that we'll end
up with too much fragmentation this way -- although I suppose we'll all end up
copying whatever AdaCore does by some sort of necessity.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, November 22, 2011  4:56 PM

...
> But I think it's very wrong to say "should never be turned off"
> about ANY checks.  If I have strong evidence (from testing, code
> reviews, independent proof tools, ...) that calls to the library won't
> fail preconditions, and I need to turn them off to meet my performance
> goals, then I want to be able to do so.
> CLAW is not such a case, because it's not performance-critical,
> because it's painting stuff on a screen.  But you can't generalize
> from that to all libraries.

I don't disagree with this basic point, but supposed "performance goals" are
usually used to justify all sorts of iffy behavior. But in actual practice,
performance is impacted only a small amount by checks, and it is very rare for
the checks to be the difference in performance.

That is, most of the time, performance is way too slow/large/whatever, and
turning off checks doesn't make enough difference. You have to switch
algorithms. Or performance is really good enough as it is, and turning off
checks just makes the program more fragile and prone to malfunction without any
real benefit.

The area between where turning off checks helps is pretty narrow. It's almost
non-existent for constraint checks (a large number of which compilers remove). I
like to think that the situation will be pretty similar for contract checks.

Specifically, my fantasy compiler (I say fantasy compiler not because I don't
know how to implement this, but more because I don't know if I'll ever have the
time to actually implement it to make it real -- and I don't want make non-real
things sound like they exist) should be able to remove most invariants and
postconditions by proving them true. Similarly, it should be able to remove most
predicates and preconditions by proving them true (based in part of the
postconditions, known to either be checked or proved true). So the incremental
effect of contract checks will be quite small.

I should note that this depends on writing "good" contracts, using only provably
"pure" functions. My fantasy compiler will surely give lots of warnings for bad
contracts (and reject them altogether in some modes). Bad contracts always have
to be evaluated and are costly - but these aren't really "contracts" given that
they change based on factors other than the object values involved. One hopes
these things aren't common.

> Commenting them out is not a good option, because then I can't
> automatically turn them back on for debug/test builds.

True enough. But that's the role of pragma Assert: put the debugging stuff it
in, not into contracts.

> Look at it another way:  The ability to turn off checks (of whatever
> sort) gives me the freedom to put in useful checks without worrying
> about how inefficient they are.  I've written some pretty complicated
> assertions, on occasion.

Which is fine. But if you write complicated (and non-provable) contracts, I hope
your compiler cuts you off at the knees. (My fantasy compiler surely will
complain loudly about such things.) Keep contracts and debugging stuff separate!
(And anything that can't be part of the production system is by definition
debugging stuff!)

> Or yet another way:  The decision to turn checks on or off properly
> belongs to the programmer, not to us language designers.

True enough. But what worries me is lumping together things that are completely
different. Debugging stuff can and should be turned off, and no one should have
to think too much about doing so. Contract stuff, OTOH, should only be turned
off under careful consideration. It's annoying to put those both under the same
setting, encouraging the confusion of thinking these things are the same
somehow.

> Erhard imagines a library carefully written by competent people, and a
> client sloppily written by nincompoops.  That is indeed a common case,
> but the opposite case, and everything in between, can also happen.

Yes, of course. But as I note, well-written contracts can be (and should be)
almost completely eliminated by compilers. So the reason for turning those off
should be fairly minimal (especially as compilers get better at optimizing
these).

The danger is confusing debugging stuff (like expensive assertions that cannot
be left in the production program -- and yes, I've written some things like
that) with contract stuff that isn't costly in the first place and should be
left in all programs with the possible exception of the handful on the razor's
edge of performance. (And, yes, I recognize the need to be able to turn these
things off for that razor's edge. I've never argued that you shouldn't be able
to turn these off at all, only that they shouldn't be lumped with "expensive
assertions" that can only be for debugging purposes.)

BTW, my understanding is that GNAT already has much finer control over
assertions and contracts than that offered by the Standard. Do you have any
feeling for how often this control is used vs. the blunt instrument given in the
Standard? If it is widely used, that suggests that the Standard is already
deficient.

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 22, 2011  10:07 PM

> I don't disagree with this basic point, but supposed "performance
> goals" are usually used to justify all sorts of iffy behavior. But in
> actual practice, performance is impacted only a small amount by
> checks, and it is very rare for the checks to be the difference in
> performance.

But checks can be a menace in terms of deactivated code in a certified
environment, so often in a 178B context people DO want to turn off all checks,
because they don't want to deal with deactivated code.

> That is, most of the time, performance is way too slow/large/whatever,
> and turning off checks doesn't make enough difference. You have to
> switch algorithms. Or performance is really good enough as it is, and
> turning off checks just makes the program more fragile and prone to
> malfunction without any real benefit.

Yes, most of the time, but there are VERY significant exceptyions.

> The area between where turning off checks helps is pretty narrow. It's
> almost non-existent for constraint checks (a large number of which
> compilers remove). I like to think that the situation will be pretty
> similar for contract checks.

That's just wrong, there are cases in which constraint checks have to be turned
off to meet performance goals.

> Specifically, my fantasy compiler (I say fantasy compiler not because
> I don't know how to implement this, but more because I don't know if
> I'll ever have the time to actually implement it to make it real --
> and I don't want make non-real things sound like they exist) should be
> able to remove most invariants and postconditions by proving them
> true. Similarly, it should be able to remove most predicates and
> preconditions by proving them true (based in part of the postconditions, known to either be checked or proved true).
> So the incremental effect of contract checks will be quite small.

Well hardly worth discussing fantasies!

> Which is fine. But if you write complicated (and non-provable)
> contracts, I hope your compiler cuts you off at the knees. (My fantasy
> compiler surely will complain loudly about such things.) Keep
> contracts and debugging stuff separate! (And anything that can't be
> part of the production system is by definition debugging stuff!)

I think you definitely are in fantasy land here, and I don't see any point
trying to set you straight, since you proclaim this to be a fantasy.

> True enough. But what worries me is lumping together things that are
> completely different. Debugging stuff can and should be turned off,
> and no one should have to think too much about doing so. Contract
> stuff, OTOH, should only be turned off under careful consideration.
> It's annoying to put those both under the same setting, encouraging
> the confusion of thinking these things are the same somehow.

For many people they are the same somehow, because assertions were always about
contracts...

> Yes, of course. But as I note, well-written contracts can be (and
> should be) almost completely eliminated by compilers. So the reason
> for turning those off should be fairly minimal (especially as
> compilers get better at optimizing these).

This idea of complete elimitation is plain nonsense, and the idea that it can
happen automatically even more nonsensical. Randy, you might want to follow the
Hi-Lite project to get a little more grounded here and also familiarize yourself
with SPARK, and what can and cannot be feasibly achieved in terms of proof of
partial correctness.

> The danger is confusing debugging stuff (like expensive assertions
> that cannot be left in the production program -- and yes, I've written
> some things like that) with contract stuff that isn't costly in the
> first place and should be left in all programs with the possible
> exception of the handful on the razor's edge of performance. (And,
> yes, I recognize the need to be able to turn these things off for that
> razor's edge. I've never argued that you shouldn't be able to turn
> these off at all, only that they shouldn't be lumped with "expensive
> assertions" that can only be for debugging purposes.)

I find your distinction between assertions and pre/postconditions etc to be
pretty bogus.

> BTW, my understanding is that GNAT already has much finer control over
> assertions and contracts than that offered by the Standard. Do you
> have any feeling for how often this control is used vs. the blunt
> instrument given in the Standard? If it is widely used, that suggests
> that the Standard is already deficient.

I have never seen any customer code using this fine level of control. It still
seems reasonable to provide it!

Actually in GNAT, we have a generalized assertion

    pragma Check (checkname, assertion [, string]);

where checkname can be referenced in a Check_Policy to turn it on or off, but I
don't know if anyone uses it.

Internally something like a precondition gets turned into

   pragma Check (Precondition, .....)

****************************************************************

From: Robert Dewar
Sent: Tuesday, November 22, 2011  11:07 PM

...
> I'm thinking about something like Claw, where the failure of a
> postcondition or invariant means that there is a bug in Claw (call
> tech support!) while the failure of a precondition or predicate means
> that there is a bug in the client's code (damn, better go fix it).
> There ought to be some differentiation between these.

I would assume that appropriate messages indicate what is going on.

****************************************************************

From: Bob Duff
Sent: Wednesday, November 23, 2011  7:26 AM

> BTW, my understanding is that GNAT already has much finer control over
> assertions and contracts than that offered by the Standard. Do you
> have any feeling for how often this control is used vs. the blunt
> instrument given in the Standard? If it is widely used, that suggests
> that the Standard is already deficient.

My evidence is not very scientific, but my vague impression is that most people
turn checks on or off for production.  I.e. not fine grained.

I think "fine grained" would be a good idea in many cases, but I suppose most
people find it to be too much trouble.

Which reminds me of another reason to have a way to turn off ALL checks:  If
you're thinking of turning off some checks, you should turn off all checks, and
measure the speed -- that tells you whether turning off SOME checks can help,
and a best-case estimate of how much.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 23, 2011  1:58 PM

> > I don't disagree with this basic point, but supposed "performance
> > goals" are usually used to justify all sorts of iffy behavior. But
> > in actual practice, performance is impacted only a small amount by
> > checks, and it is very rare for the checks to be the difference in
> > performance.
>
> But checks can be a menace in terms of deactivated code in a certified
> environment, so often in a 178B context people DO want to turn off all
> checks, because they don't want to deal with deactivated code.

I don't understand. A check of the sort I'm talking about is by definition not
something "deactivated". Either the compiler can prove it to be OK, in which
case it doesn't appear in the code at all (it's essentially a comment), or it is
executed everytime the  runs. In which case it is an integral part of the code.

I'd expect problems in terms of 178B for the handlers of check failures (since
there wouldn't be an obvious way to execute or verify them), but not the checks
themselves. Perhaps you meant the handlers?

...
> > The area between where turning off checks helps is pretty narrow.
> > It's almost non-existent for constraint checks (a large number of
> > which compilers remove). I like to think that the situation will be
> > pretty similar for contract checks.
>
> That's just wrong, there are cases in which constraint checks have to
> be turned off to meet performance goals.

I said "almost non-existent". The only time it makes sense to turn off
constraint checks is in a loop, verified to be very "hot" in terms of program
performance, and no better algorithm is available. And even then, you would be
better off restructuring the loop to move the checks outside of it rather than
turning them off (that's usually possible with the addition of subtypes).

...
> > Which is fine. But if you write complicated (and non-provable)
> > contracts, I hope your compiler cuts you off at the knees. (My
> > fantasy compiler surely will complain loudly about such things.)
> > Keep contracts and debugging stuff separate! (And anything that
> > can't be part of the production system is by definition debugging
> > stuff!)
>
> I think you definitely are in fantasy land here, and I don't see any
> point trying to set you straight, since you proclaim this to be a
> fantasy.

I'd like you try. The only reason I proclaimed this a fantasy is because I have
no idea if I'll ever be able to spend the 2-3 months of time to implement
aspect_specifications and Pre/Post in the Janus/Ada *front-end*. That will be a
*lot* of work.

But the "proving" is just the stuff the Janus/Ada optimizer (and I would expect
every other compiler optimizer) already does. I'd add two very simple extensions
to what it already does: (1) add support for "facts" to the intermediate code --
that is expressions that the optimizer knows the value of without explicitly
evaluating them (so they would have no impact on generated code); (2) extending
common-subexpression elimination to function calls of functions that are
provably pure (using a new categorization).

The only real issue I see with this is that the Janus/Ada optimizer is not set
up to give detailed feedback to the user, which means that it can only report
that it was unable to "prove" a postcondition -- it can't give any indication as
to why. Obviously that is something that will need future enhancement.

> > True enough. But what worries me is lumping together things that are
> > completely different. Debugging stuff can and should be turned off,
> > and no one should have to think too much about doing so. Contract
> > stuff, OTOH, should only be turned off under careful consideration.
> > It's annoying to put those both under the same setting, encouraging
> > the confusion of thinking these things are the same somehow.
>
> For many people they are the same somehow, because assertions were
> always about contracts...

Hiding contracts in the body was always a bad idea. In any case, there is
clearly a grey area, and it will move as compiler (and other tools) technology
improves. But I would say that anything that a compiler cannot use in proving
should be an assertion (that is, a debugging aid) rather than part of a
contract. That means to me that such things should not change the correctness of
the program if turned off, and they should be suppressable independent of those
things that can be used automatically.

> > Yes, of course. But as I note, well-written contracts can be (and
> > should be) almost completely eliminated by compilers. So the reason
> > for turning those off should be fairly minimal (especially as
> > compilers get better at optimizing these).
>
> This idea of complete elimitation is plain nonsense, and the idea that
> it can happen automatically even more nonsensical.
> Randy, you might want to follow the Hi-Lite project to get a little
> more grounded here and also familiarize yourself with SPARK, and what
> can and cannot be feasibly achieved in terms of proof of partial
> correctness.

I think SPARK is doing more harm than good at this point. It was very useful as
a proof-of-concept, but it requires a mindset and leap that prevents the vast
majority of programmers from every using any part of it. The effect is that they
are solving the wrong problem.

In order for something to be used by a majority of (Ada) programmers, it has to
have at least the following characteristics:
(1) Little additional work required;
(2) Little degrading of performance;
(3) Has to be usable in small amounts.

The last is the most important. The way I and probably many other Ada
programmers learned the benefit of Ada constraint checks was to write some code,
and then have a bug detected by such a check. It was noticed that (a) fixing the
bug was simple since the check pinpointed the location of the problem, and (b)
finding and fixing the bug would have been much harder without the check. That
caused me to add additional constraints to future programs, which found
additional bugs. The feedback back loop increased the adoption of the checks to
the point that I will only consider turning them off for extreme performance
reasons.

I think we have to set up the same sort of feedback loop for contracts. That
means that simple contracts should have little impact on performance (and in
some cases, they might even help performance by giving additional information to
the optimizer and code generator). (I also note that this focus also provides
obvious ways to leverage multicore host machines, which is good as a lot of
these techniques are not easily parallelizable.)

As such, I'm concentrating on what can be done with existing technology -- that
is, subprogram level understanding using well-known optimization techniques. I'm
sure we'll want to go beyond that eventually, but we need several iterations of
the feedback loop in order to build up customer demand for such things. (And
then we'll have to add exception contracts, side-effect contracts, and similar
things to Ada to support stronger proofs.)

> > The danger is confusing debugging stuff (like expensive assertions
> > that cannot be left in the production program -- and yes, I've
> > written some things like that) with contract stuff that isn't costly
> > in the first place and should be left in all programs with the
> > possible exception of the handful on the razor's edge of
> > performance. (And, yes, I recognize the need to be able to turn
> > these things off for that razor's edge. I've never argued that you
> > shouldn't be able to turn these off at all, only that they shouldn't
> > be lumped with "expensive assertions" that can only be for debugging
> > purposes.)
>
> I find your distinction between assertions and pre/postconditions etc
> to be pretty bogus.

Fair enough. But then there will never be any real progress here, because few
people will use expensive contracts that slow down their programs. And I
*really* don't want to go back to the bad old days of multiple versions of
programs to test (one with checks and one without). It's like the old saw says:
create and test a car with seatbelts, then remove them in the production
version.

So I want to separate the contracts (an integral part of program correctness,
and almost never turned off) from the assertions (expensive stuff that has
little impact on program correctness, can be turned off without impact). I
suspect that one probably could easily find several additional categories, which
you may want to control separately.

Note that one of the reasons why I supported the "assert_on_start" and
"assert_on_exit" ideas is that these provide a place to put those expensive
assertions that cannot be reasoned about with simple technology. I surely agree
that just because something is expensive is no good reason not to include it.
But simply because you have a few expensive assertions around is no good reason
to turn off the bulk of the contracts which are cheap and easily eliminated
completely.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:19 PM

...
> My view of assertions is a bit different: an assertion is something
> that ought to be True at a given point, but it doesn't affect the
> correctness of the program. IMHO, checks that do affect the
> correctness of the program should not be given as an assertion (pragma
> Assert), but rather be directly part of the program. For instance, if
> you have an if statement that handles two possible cases, but other
> cases are not handled, there ought to be some else branch with a bug
> box or exception raise in it -- not some assertion that can be
> ignored. (I've yet to see a case where a pragma Assert could do
> something that you couldn't do with regular code; that's not true of
> our old Condcomp facility, which allows conditionally compiled
> declarations and
> pragmas.)

OK, for me, I am with Tuck, assertions are definitely about preconditions and
postconditions, and if false, something is just as wrong as if a Pre or Post
aspect was violated

> I realize that pragma Assert can be used in other ways than I outlined
> above, but I always thought that the above was the intent -- it would
> surely be the way that I'd use it (if we had implemented it at all; we
> have not done so to date, so I've never actually used it).

No, that's nbot at all the intent as I see it, in fact I find your
intepretration very odd.

>  Thus, pragma Assert is purely a debugging aid; it never has an affect
> on any sort of correctness and it can be ignored without any harmful
> effects.

I absolutely disagree with this view of assertions. The primary purpose of
assertions is to inform the reader of pre and post conditions for sections of
code. They are valuable even if turned off, and doing the same thing with
regular code is actively confusing. Assertions are NOT part of the program, they
are statements about the program (aka contracts) at least as I use them. Yes,
they can be turned on and just as Pre/Post are useful debugging aids when turned
on, so our assertions.

Once again, I see no substantial differences between assersions and pre/post
conditions.

Have a look for example at the sources of einfo.ads/adb in the GNAT compiler.
The subprograms in the body are full of assertions like:

>    procedure Set_Non_Binary_Modulus (Id : E; V : B := True) is
>    begin
>       pragma Assert (Is_Type (Id) and then Is_Base_Type (Id));
>       Set_Flag58 (Id, V);
>    end Set_Non_Binary_Modulus;

Here the assert is to be read as, and behaves as, a precondition.
Any call that does not meet this precondition is wrong. Yes, it would be much
better if these were expressed as preconditions in the spec, but we didn't have
that capability fifteen years ago. We have an internal ticket to replace many of
our assertions with pre post conditions, but that's not always feasible.
Consider this kind of codce

   if Ekind (E) = E_Signed_Integer then
      ...

   elsif Ekind (E) = E_Modular_Integer then
      ...

   else pragma Assert (Is_Floating_Point_Type (E));
      ...

Here the pragma assert is saying that the only piossibility (in the absence of
someone screweing up preconditions somewhere) is a floating-point type. It does
not need to be tested, since it is the only possibility, but this is very useful
documentation, and of course we can turn on assertions, and then, like all
contracts, we enable useful debugging capabilities.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:21 PM

Overall comment from Robert. I don't think anything needs to be changed here.
Let's let usage determine the need for finer grained control, and next time
around, we can consider whether to standardize some of this finer control.

In practice it won't make much difference, most implementations go out of their
way to accomdoate pragmas/attributes/restrictions etc from other
implementations, we have dozens of pragmas that are there just because some
other implementation invented them.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:23 PM

> Thinking more about future users...:
>
> What I would like to be able to is to turn off Assertions and
> Postconditions in MY code, because I have verified it to my heart's
> content. But what I would like to continue checking is the
> Preconditions of services that my library offers.
> After all, there is no limit to the s... of people (not reading
> contracts) and I want to ensure that my code works as advertised.
>
> Unfortunately, it looks like it is an all-or-nothing policy that is
> provided today. If that issue is (re)opened, I would argue for the
> differentiation above.

Don't worry, so far every implementation that provides pre and post conditions
provides the selective control you ask for. I will be VERY surprised if that
does not continue to be the case.

> If it is not re-opened then I want to note for 2020 that the upward
> incompatibility of billions and billions of lines of code relying on
> turning off precondition checks exists - and it would be a good thing
> to cause that incompatibility ;-)

I agree more control is needed, I just think it's premature to try to dictate to
implementations what it should be, let users and customers decide.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:31 PM

> ...
>> But for those who have, they serve very much the same purpose as
>> these new contracts.  They are essentially higher-level constraint
>> checks.
>
> That's an abuse of the construct, IMHO.

Very peculiar viewpoint, in that case, most people using assertions are in your
idiosyncratic view, abusing it, but I find this a bit silly, since we know in
practice that most users of assertions are in fact carrying out this abuse,
regarding it as the proper thing to do

>> To imply that somehow they are fundamentally different seems like an
>> unjustifiable leap.
>
> They *are* fundamentally different:

No they aren't

> (1) As pragmas, they should never have an effect on the dynamic
> correctness of the program. It should always be possible to erase all
> of the pragmas and get a functioning program. Anything else is an
> abuse of pragmas. We got rid of almost all of the offending pragmas in Ada
> 2012.

That's a purist position that bares no relationship to reality. E.g.
if you take away a pragma that specifies the queing policy, of course the
program may fail, I would say half the pragmas in existence, both language
defined and impl defined are like that.

pragmas that affect dynamic behavior of the program (I really don't know what
you mean by dynamic correctness, to most programmers correct means the program
is doing what it is meant to do)

Detect_Blocking
Default_Storage_Pool
Discard_Names
Priorty_Specific_Dispatching
Locking_Policy
Restrictions
Atomic
Atomic_Components
Attach_Handler
Convention
Elaborate_All
Export
Import
Interrupt_Priority
Linker_Options
Pack
Priority
Storage_Size
Volatile
Volatile_Components

In fact the number of pragmas that do NOT affect the dynamic behavior of a
program is very small.

So if your viewpoint is based on this fantasy that pragmas do not affect the
correctness of a program, they are built on a foundation of sand.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:32 PM

Really one conclusion from this thread is that there is no consensus on whether
a late change is desirable, let alone important enough to do as a late change.

So it seems obvious to me that the proper action is to leave things alone. You
would need a VERY clear consensus to change something like this at this stage!

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  2:56 PM

>> But checks can be a menace in terms of deactivated code in a
>> certified environment, so often in a 178B context people DO want to
>> turn off all checks, because they don't want to deal with deactivated
>> code.
>
> I don't understand. A check of the sort I'm talking about is by
> definition not something "deactivated". Either the compiler can prove
> it to be OK, in which case it doesn't appear in the code at all (it's
> essentially a comment), or it is executed everytime the  runs. In
> which case it is an integral part of the code.

> I'd expect problems in terms of 178B for the handlers of check
> failures (since there wouldn't be an obvious way to execute or verify
> them), but not the checks themselves. Perhaps you meant the handlers?

I mean that if you have

    if A < 10 then
      raise COnstraint_Error;
    end if;

then you will have deactivated code (the raise can never be executed).
Now if you are doing source level coverage (which is really what 178B requires),
you may be able to deal with this with a suitable traceability study. But in
practice many producers of safety critical code (and not a few DER's) prefer to
see every line of object code executed in tests. It is controversial whether
178B requires this, but let me say for sure Robert Dewar requires it :-)

If I was managing a SC project, I would want to see 100% coverage at the object
level, and having to deal with all these cases by injection tests would be too
painful, so I would probably go with turnning checks off. After all if you are
using a SPARK approach in which you prove that no constraint errors can occur,
what's the point in leaving in junk dead tests.

> I said "almost non-existent". The only time it makes sense to turn off
> constraint checks is in a loop, verified to be very "hot" in terms of
> program performance, and no better algorithm is available. And even
> then, you would be better off restructuring the loop to move the
> checks outside of it rather than turning them off (that's usually
> possible with the addition of subtypes).

This is just totally at odds with how many people use the language.
There is nothing necessarily wrong with making sure the language covers RB's
idiosyncratic views on how the language should be used, as well as everyone
else's idiosyncratic views, but we don't want to designt the language so it is
ONLY suitable for this usage view.

> I'd like you try. The only reason I proclaimed this a fantasy is
> because I have no idea if I'll ever be able to spend the 2-3 months of
> time to implement aspect_specifications and Pre/Post in the Janus/Ada *front-end*.
> That will be a *lot* of work.

As I say, I recommend you take a close look both at the SPARK technology and at
the Hi-Lite project, these are both very real.

> But the "proving" is just the stuff the Janus/Ada optimizer (and I
> would expect every other compiler optimizer) already does. I'd add two
> very simple extensions to what it already does: (1) add support for
> "facts" to the intermediate code -- that is expressions that the
> optimizer knows the value of without explicitly evaluating them (so
> they would have no impact on generated code); (2) extending
> common-subexpression elimination to function calls of functions that are provably pure (using a new categorization).

It is MUCH MUCH harder than you think, and lots of people have spent lots of
time working on these problems, and the naive optimism you express is not shared
by those people.

> Hiding contracts in the body was always a bad idea. In any case, there
> is clearly a grey area, and it will move as compiler (and other tools)
> technology improves. But I would say that anything that a compiler
> cannot use in proving should be an assertion (that is, a debugging
> aid) rather than part of a contract. That means to me that such things
> should not change the correctness of the program if turned off, and
> they should be suppressable independent of those things that can be used automatically.

Well some preconditions and postconditions belong naturally in the body.
Consider a memo function. The memoizing should be totally invisible in the spec,
and generally the caller won't even be able to see or talk about the memo data.
But it makes perfect sense to write preconditions and postconditions in the body
saying what the memo data must look like on entry and exit.

> I think SPARK is doing more harm than good at this point. It was very
> useful as a proof-of-concept, but it requires a mindset and leap that
> prevents the vast majority of programmers from every using any part of
> it. The effect is that they are solving the wrong problem.

I have no idea what you mean, but I am pretty sure you are not really familiar
with SPARK, or the associated proof technologies. Are you even familiar with the
annotation language?

> In order for something to be used by a majority of (Ada) programmers,
> it has to have at least the following characteristics:
> (1) Little additional work required;
> (2) Little degrading of performance;
> (3) Has to be usable in small amounts.

Again, how about looking at Hi-Lite which is precisely about figuring out the
extent to which formal methods can be employed using roughly these criteria.
Randy, while you sit fantasizing over what can be done, other people are
devoting huge amounts of effort to thinking

> The last is the most important. The way I and probably many other Ada
> programmers learned the benefit of Ada constraint checks was to write
> some code, and then have a bug detected by such a check. It was
> noticed that (a) fixing the bug was simple since the check pinpointed
> the location of the problem, and (b) finding and fixing the bug would
> have been much harder without the check. That caused me to add
> additional constraints to future programs, which found additional
> bugs. The feedback back loop increased the adoption of the checks to
> the point that I will only consider turning them off for extreme performance reasons.

Yes, we know contraint checks are a relatively simple case. In the SPARK context
for example, it has proved practical to prove large applications like iFacts to
be free of any run-time errors, but it has NOT proved feasible to prove partial
correctness for the whole application.

> As such, I'm concentrating on what can be done with existing
> technology -- that is, subprogram level understanding using well-known
> optimization techniques. I'm sure we'll want to go beyond that
> eventually, but we need several iterations of the feedback loop in
> order to build up customer demand for such things. (And then we'll
> have to add exception contracts, side-effect contracts, and similar
> things to Ada to support stronger
> proofs.)

We are already WAY beyond this. And there is very real customer demand Have a
look at http://www.open-do.org/projects/hi-lite/. There are many large scale
users of Ada in safety-critical contexts who are very interested, especially in
the environment of 178-C in the extent to which unit proof can replace unit
testing.

> Fair enough. But then there will never be any real progress here,
> because few people will use expensive contracts that slow down their
> programs. And I
> *really* don't want to go back to the bad old days of multiple
> versions of programs to test (one with checks and one without). It's
> like the old saw
> says: create and test a car with seatbelts, then remove them in the
> production version.

People DO use expensive contracts that slow down their programs, ALL THE TIME!
Remember that at AdaCore, we have years of experience here. The precondition and
postcondition pragmas of GNAT which have been around for over three years, were
developed in response to customer demand by large customers developing large
scale safety-critical applications. It really doesn't matter than the tests may
be expensive if enabled at run time, they won't be enabled in the final build.

> So I want to separate the contracts (an integral part of program
> correctness, and almost never turned off) from the assertions
> (expensive stuff that has little impact on program correctness, can be
> turned off without impact). I suspect that one probably could easily
> find several additional categories, which you may want to control separately.

the almost never turned off does not correspond with how we see our customers
using these features *at all*.

And indeed even after we replace many of the assertions in GNAT itself with pre
and post conditions, we will normally turn them all off as we do now for
production builds of the compiler, since turning assertions on does compromise
compiler performance3 significantly, and this matters to many people. We do
builds internally with assertions turned on, and these are indeed useful for
debugging porposes.

> Note that one of the reasons why I supported the "assert_on_start" and
> "assert_on_exit" ideas is that these provide a place to put those
> expensive assertions that cannot be reasoned about with simple
> technology. I surely agree that just because something is expensive is
> no good reason not to include it. But simply because you have a few
> expensive assertions around is no good reason to turn off the bulk of
> the contracts which are cheap and easily eliminated completely.

The idea that preconeditions and postconditions will be restricted to simple
things that can "be reasoned about with simple technology":

a) bares no relation to the way people are actually using the feature

b) does not correspond with my expectations of how people will use
    the technology

c) does not correspond with my recommendations of how people *should*
    use the technology

I have no objection to making sure that what we define is reasonably usage for
your (to me very peculiar) view of how these features should be used, but I
would be appalled to think this was the official view of the language design, or
that the designm would be compromised by this viewpoint (I find assert_on_start
and assert_on_exit deeply flawed if they are motivated by dealing with expensive
stuff).

I contest the idea that the bulk of contracts are cheap and easily eliminated.
Again look at Hi-Lite to get a better feel for the state of the art in this
respect.

Even just eliminating all contstraint checks is far from trivial (read some of
the SPARK papers on this subject).

****************************************************************

From: Bob Duff
Sent: Wednesday, November 23, 2011  2:59 PM

>...But I would say that anything that a compiler cannot  use in proving
>should be an assertion (that is, a debugging aid) rather than  part of
>a contract.

Could we please settle on terminology?  Preferably somewhat standard
terminology?

The term "assertion" means pragma Assert, precondition, postcondition,
invariant, and predicate.  Bertrand Meyer uses it that way, and I think it makes
sense.  Probably constraints and null exclusions should also be called
assertions.

I really think equating "assertion" and "debugging aid" will cause nothing but
confusion.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 23, 2011  4:11 PM

> > I don't understand. A check of the sort I'm talking about is by
> > definition not something "deactivated". Either the compiler can
> > prove it to be OK, in which case it doesn't appear in the code at
> > all (it's essentially a comment), or it is executed everytime the
> > runs. In which case it is an integral part of the code.
>
> > I'd expect problems in terms of 178B for the handlers of check
> > failures (since there wouldn't be an obvious way to execute or
> > verify them), but not the checks themselves. Perhaps you meant the handlers?
>
> I mean that if you have
>
>     if A < 10 then
>       raise COnstraint_Error;
>     end if;
>
> then you will have deactivated code (the raise can never be executed).

I see. But this is not actually what will be generated in the object code (at
least for language-defined checks).

> Now if you are doing source level coverage (which is really what 178B
> requires), you may be able to deal with this with a suitable
> traceability study. But in practice many producers of safety critical
> code (and not a few DER's) prefer to see every line of object code
> executed in tests. It is controversial whether 178B requires this, but
> let me say for sure Robert Dewar requires it :-)
>
> If I was managing a SC project, I would want to see 100% coverage at
> the object level, and having to deal with all these cases by injection
> tests would be too painful, so I would probably go with turnning
> checks off. After all if you are using a SPARK approach in which you
> prove that no constraint errors can occur, what's the point in leaving
> in junk dead tests.

I agree with this. But it seems to me that you don't need to test every possible
check, only one. That's because in practice the code will look something like:

    Mov EAX,[A]
    Cmp EAX, 10
    Jl  Check_Failed

And every instruction of the object code here will be executed whether or not
the check fails. The branch might even be a jump to the handler, if it is
local).

I suppose if your requirement is to exercise every possible *path*, then you
have to remove all of the checks, but otherwise, you only need remove complex
ones with dead code. (And there aren't many of those that are language-defined.)

> > I said "almost non-existent". The only time it makes sense to turn
> > off constraint checks is in a loop, verified to be very "hot" in
> > terms of program performance, and no better algorithm is available.
> > And even then, you would be better off restructuring the loop to
> > move the checks outside of it rather than turning them off (that's
> > usually possible with the addition of subtypes).
>
> This is just totally at odds with how many people use the language.
> There is nothing necessarily wrong with making sure the language
> covers RB's idiosyncratic views on how the language should be used, as
> well as everyone else's idiosyncratic views, but we don't want to
> designt the language so it is ONLY suitable for this usage view.

I agree with you in general. I started out as one of those "many people". I
eventually learned I was wrong, and also got bigger machines to run my code on.
The language should discourage bad practices and misuse, but not to the extent
of preventing things that need to be done occasionally. I surely would not
suggest eliminating the ability to turn off checks, what bothers me of course is
the requirement to treat them all the same, when they are clearly not the same.

...
> > But the "proving" is just the stuff the Janus/Ada optimizer (and I
> > would expect every other compiler optimizer) already does. I'd add
> > two very simple extensions to what it already does: (1) add support
> > for "facts" to the intermediate code -- that is expressions that the
> > optimizer knows the value of without explicitly evaluating them (so
> > they would have no impact on generated code); (2) extending
> > common-subexpression elimination to function calls of functions that
> > are provably pure (using a new categorization).
>
> It is MUCH MUCH harder than you think, and lots of people have spent
> lots of time working on these problems, and the naive optimism you
> express is not shared by those people.

Trying to do it all surely is harder than I am expressing here. But I only am
interested in the 75% that is easy, because that has the potential to make
contracts as cheap as constraint checks (can't eliminate *all* of those either,
it just matters that you eliminate most).

> > Hiding contracts in the body was always a bad idea. In any case,
> > there is clearly a grey area, and it will move as compiler (and
> > other tools) technology improves. But I would say that anything that
> > a compiler cannot use in proving should be an assertion (that is, a
> > debugging
> > aid) rather than part of a contract. That means to me that such
> > things should not change the correctness of the program if turned
> > off, and they should be suppressable independent of those things
> that can be used automatically.
>
> Well some preconditions and postconditions belong naturally in the body.
> Consider a memo function. The memoizing should be totally invisible in
> the spec, and generally the caller won't even be able to see or talk
> about the memo data. But it makes perfect sense to write preconditions
> and postconditions in the body saying what the memo data must look
> like on entry and exit.

I agree that some things naturally belong in the body -- those clearly are not
part of the contract. They're some other kind of thing (I've been calling them
assertions, but Bob hates that, so I'll just say that they need a good name -
"non-contract assertions" is the best I've got, and it isn't great).

I'd argue that such things matter not to the client at all, and probably don't
matter much to the implementation of the body either. Which makes them a very
different sort of thing to a contract assertion -- even a (contract)
postcondition which can be used as an assumption at the call site.

> > I think SPARK is doing more harm than good at this point. It was
> > very useful as a proof-of-concept, but it requires a mindset and
> > leap that prevents the vast majority of programmers from every using
> > any part of it. The effect is that they are solving the wrong problem.
>
> I have no idea what you mean, but I am pretty sure you are not really
> familiar with SPARK, or the associated proof technologies. Are you
> even familiar with the annotation language?

I'm familiar enough to know that there is essentially no circumstance where I
could use it, as it has no support for dynamic dispatching, exceptions, or
references (access types or some real equivalent, not Fortran 66-type tricks). I
know it progressed some from the days when I studied it extensively (about 10
years ago), but not in ways that would be useful to me or many other Ada
programmers.

Anyway, the big problem I see with SPARK is that you pretty much have to use it
exclusively in some significant chunk of code to get any benefit. Which prevents
the sort of incremental adoption that is really needed to change the attitudes
of the typical programmer.

...
> Again, how about looking at Hi-Lite which is precisely about figuring
> out the extent to which formal methods can be employed using roughly
> these criteria. Randy, while you sit fantasizing over what can be
> done, other people are devoting huge amounts of effort to thinking

The only reason I'm just thinking rather than doing is lack of time and $$$ to
implement something. Prior commitments (to Ada 2012)  have to be done first.

> > The last is the most important. The way I and probably many other
> > Ada programmers learned the benefit of Ada constraint checks was to
> > write some code, and then have a bug detected by such a check. It
> > was noticed that (a) fixing the bug was simple since the check
> > pinpointed the location of the problem, and (b) finding and fixing
> > the bug would have been much harder without the check. That caused
> > me to add additional constraints to future programs, which found
> > additional bugs. The feedback back loop increased the adoption of
> > the checks to the point that I will only consider turning them off
> > for extreme performance reasons.
>
> Yes, we know contraint checks are a relatively simple case.
> In the SPARK context for example, it has proved practical to prove
> large applications like iFacts to be free of any run-time errors, but
> it has NOT proved feasible to prove partial correctness for the whole
> application.

I'm not certain I understand what you mean by "partial correctness", but if I am
even close, that seems like an obvious statement. And even if it was possible,
I'd leave that to others to do. I'm not talking about anything like that; I
don't want to prove anything larger than a subprogram. You can chain those
together to prove something larger, but I doubt very much it would ever come
close to "correctness". I just want to prove the obvious stuff, both for
performance reasons (so contracts don't cost much in practice) and to provide an
aid as to where things are going wrong.

> > As such, I'm concentrating on what can be done with existing
> > technology -- that is, subprogram level understanding using
> > well-known optimization techniques. I'm sure we'll want to go beyond
> > that eventually, but we need several iterations of the feedback loop
> > in order to build up customer demand for such things. (And then
> > we'll have to add exception contracts, side-effect contracts, and
> > similar things to Ada to support stronger
> > proofs.)
>
> We are already WAY beyond this. And there is very real customer demand
> Have a look at http://www.open-do.org/projects/hi-lite/. There are
> many large scale users of Ada in safety-critical contexts who are very
> interested, especially in the environment of 178-C in the extent to
> which unit proof can replace unit testing.

I looked at the site and didn't see anything concrete, just a lot of motherhood
statements. I realize that there had to be a lot of that in the grant proposals,
but I would like to see more than that to feel that anything is really being
accomplished. How is Hi-Lite going to reach its goals.

And clearly, the users requiring 178 and the like are a tiny minority. It's
perfectly good to support them (they surely need it), but their needs are far
from the mainstream. As such "Hi-Lite" is just a corner of what I want to
accomplish. (If you don't have big goals, there is no point; and if the goals
are attainable you probably will end up disappointed. :-) I would like to see an
environment where all programmers include this sort of information in their
programs, and all compilers and tools use that information to detect (some) bugs
immediately. That can only be approached incrementally, and it requires a
grass-roots effort -- it's not going to happen just from big projects where
management can mandate whatever they want/need.

...
> People DO use expensive contracts that slow down their programs, ALL
> THE TIME! Remember that at AdaCore, we have years of experience here.
> The precondition and postcondition pragmas of GNAT which have been
> around for over three years, were developed in response to customer
> demand by large customers developing large scale safety-critical
> applications.
> It really doesn't matter than the tests may be expensive if enabled at
> run time, they won't be enabled in the final build.

Which is exactly wrong: leaving the garage without seatbelts. I understand that
there are reasons for doing this, but it doesn't make it any more right.

And I'm personally not that interested in "safety-critical applications",
because these people will almost always do the right thing ultimately -- they
have almost no other choice (they'd be exposed to all sorts of liability
otherwise). I'm much more concerned about the mass of less critical applications
that still would benefit from fewer errors (that would be all of them!)

I've wasted too much of my (and your) time with this, so I'll stop here. No need
to convince each other -- time will tell.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, November 23, 2011  4:25 PM

> The term "assertion" means pragma Assert, precondition, postcondition,
> invariant, and predicate.  Bertrand Meyer uses it that way, and I
> think it makes sense.  Probably constraints and null exclusions should
> also be called assertions.
>
> I really think equating "assertion" and "debugging aid" will cause
> nothing but confusion.

OK, I'll stop trying to forward this discussion.

I could live with some better terminology for the separation, but the separation
is clearly real and those that chose to ignore it force programmers into a
corner where they have to choose between a too-slow program with checks on, or a
decently performing program that is no better than a C program. We have the
technology to prevent the need of this Hobson's choice, and it's sad not to be
able to get any traction with it.

Beyond that, I find it incredibly sad that people want to drive Ada into a box
where it is only useful for large safety-critical applications. *All*
applications can benefit from this sort of technology, but not if it is turned
into a difficult formal language that only a few high priests can understand.
And that's what I'm getting out of this discussion.

Probably you are all right, and there is no real value to the beginner and
hobbyist anymore, since they can't be monetized. Probably I'd be best off
stopping thinking for myself and just becoming one of the sheep punching a
clock. Because the alternative isn't pretty.

****************************************************************

From: John Barnes
Sent: Wednesday, November 23, 2011  4:30 PM

Partial correctness simply means that a program is proved to be correct provided
it terminates. It's nothing to do with the proof being otherwisee flaky. Mostly
if a program has been proved to be partially correct then it really is correct
but there are amusing examples where all the proof comes out OK yet the program
is flawed because it cannot be proved to terminate in some cases.

There is a simple example on page 289 of my Spark book. It's a factorial
function. It looks OK but it loops for ever in one case.

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  4:57 PM

> Partial correctness simply means that a program is proved to be
> correct provided it terminates. It's nothing to do with the proof
> being otherwisee flaky. Mostly if a program has been proved to be
> partially correct then it really is correct but there are amusing
> examples where all the proof comes out OK yet the program is flawed
> because it cannot be proved to terminate in some cases.

In the SPARK class, one of the examples was a integer square root. You were not
asked to prove partial correctness, but I did anyway. I programmed a binary
search, and tested as the termination condition that I actually had the square
root. Obviously this only terminates if it correctly computes the square root.
However, the trick in binary searches is always to get the termination correct
and make sure you don't go into an infinite loop :-) Of course I did not prove
that.

> There is a simple example on page 289 of my Spark book. It's a
> factorial function. It looks OK but it loops for ever in one case.

Yes, a very nice example.

BTW Randy, it would be a mistake to think that Hi-Lite is ONLY relevant to
178B/C environments, the purpose is precisely to make proof of preconditions and
postconditions more generally accessible.

****************************************************************

From: John Barnes
Sent: Thursday, November 24, 2011  9:31 AM

I contrived it by accident when giving a Spark course in York. One thing it
taught me was the value of for loops which by their very nature always
terminate. And by contrast I always avoid while loops.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 24, 2011  9:53 AM

Well *always* sounds a bit suspicious, not everything is in the primitive
recursive domain!

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  4:51 PM

> I see. But this is not actually what will be generated in the object
> code (at least for language-defined checks).

Yes it is, what else are you thinking of (certainly you don't want to use the
built-in x86 operations like the range check, they are pipline catastrophes.

> I agree with this. But it seems to me that you don't need to test
> every possible check, only one. That's because in practice the code
> will look something like:
>
>      Mov EAX,[A]
>      Cmp EAX, 10
>      Jl  Check_Failed

well that's not what it will look like for us, since we maintain traceability on
what check failed.

> I suppose if your requirement is to exercise every possible *path*,
> then you have to remove all of the checks, but otherwise, you only
> need remove complex ones with dead code. (And there aren't many of
> those that are
> language-defined.)

Right, if you have a JL, it has to execute both ways even in simple coverage.

> I agree with you in general. I started out as one of those "many
> people". I eventually learned I was wrong, and also got bigger
> machines to run my code on. The language should discourage bad
> practices and misuse, but not to the extent of preventing things that
> need to be done occasionally. I surely would not suggest eliminating
> the ability to turn off checks, what bothers me of course is the
> requirement to treat them all the same, when they are clearly not the same.

But checks are seldom turned on

> I'm familiar enough to know that there is essentially no circumstance
> where I could use it, as it has no support for dynamic dispatching,
> exceptions, or references (access types or some real equivalent, not
> Fortran 66-type tricks). I know it progressed some from the days when
> I studied it extensively (about 10 years ago), but not in ways that
> would be useful to me or many other Ada programmers.

Well do you write safety-critical code at all? If not you really don't have the
right context, people usually severely subset in the SC case. Certainly you
would be very surprised to see access types and dynamic storage allocation in an
SC app. So the SPARK restrictions in practice correspond with the subset that
people anyway.

> Anyway, the big problem I see with SPARK is that you pretty much have
> to use it exclusively in some significant chunk of code to get any
> benefit. Which prevents the sort of incremental adoption that is
> really needed to change the attitudes of the typical programmer.

Well SC apps are more likely to be generated from scratch anyway, and we are not
talking typical programmer when it comes to SC apps. So SPARK is not for the
environment you are thinking in terms of (gewnertal purpose programming using
the whole language).

> ...
>> Again, how about looking at Hi-Lite which is precisely about figuring
>> out the extent to which formal methods can be employed using roughly
>> these criteria. Randy, while you sit fantasizing over what can be
>> done, other people are devoting huge amounts of effort to thinking
>
> The only reason I'm just thinking rather than doing is lack of time
> and $$$ to implement something. Prior commitments (to Ada 2012)  have
> to be done first.

Well take a quick look at the Hi-Lite pages, how much effort is that, I think
you will find them interesting

> I'm not certain I understand what you mean by "partial correctness",
> but if I am even close, that seems like an obvious statement. And even
> if it was possible, I'd leave that to others to do. I'm not talking
> about anything like that; I don't want to prove anything larger than a
> subprogram. You can chain those together to prove something larger,
> but I doubt very much it would ever come close to "correctness". I
> just want to prove the obvious stuff, both for performance reasons (so
> contracts don't cost much in
> practice) and to provide an aid as to where things are going wrong.

Gosh, I am quite surprised you don't know what partial correctness means. This
is a term of art in proof of program correctness that is very old, at least
decades (so old I have trouble tracking down first use, everyone even vageuly
associated with proof techniques knows this term).

Briefly, proving partial correctness means that IF the program terminates THEN
you your proof says something about the results. If a single subprogram is
involved, then it would mean for example proving that IF the preconditions hold,
and IF thew subprogram terminates, then the postconditions hold.

Proving termination (total correctness) is far far harder.

> I looked at the site and didn't see anything concrete, just a lot of
> motherhood statements. I realize that there had to be a lot of that in
> the grant proposals, but I would like to see more than that to feel
> that anything is really being accomplished. How is Hi-Lite going to
> reach its goals.

Did you read the technical papers? I don't think you looked hard enough!

> And clearly, the users requiring 178 and the like are a tiny minority.
> It's perfectly good to support them (they surely need it), but their
> needs are far from the mainstream. As such "Hi-Lite" is just a corner
> of what I want to accomplish. (If you don't have big goals, there is
> no point; and if the goals are attainable you probably will end up
> disappointed. :-) I would like to see an environment where all
> programmers include this sort of information in their programs, and
> all compilers and tools use that information to detect (some) bugs
> immediately. That can only be approached incrementally, and it
> requires a grass-roots effort -- it's not going to happen just from big
> projects where management can mandate whatever they want/need.

Randy, I think you have a LOT to study before understanding the issues here :-)

> Which is exactly wrong: leaving the garage without seatbelts. I
> understand that there are reasons for doing this, but it doesn't make
> it any more right.

If you can prove the car won't crash, seatbelts are not needed. It is pretty
useless for a flight control system to get a constraint error :-)

****************************************************************

From: Robert Dewar
Sent: Wednesday, November 23, 2011  5:04 PM

>> I really think equating "assertion" and "debugging aid" will cause
>> nothing but confusion.
>
> OK, I'll stop trying to forward this discussion.
>
> I could live with some better terminology for the separation, but the
> separation is clearly real

Well you think it's real, that does not make it "clearly real", and I don't find
the separation meaningful at all. And I gather that Tuck agrees with this.

> and those that chose to ignore it force programmers into a corner
> where they have to choose between a too-slow program with checks on,
> or a decently performing program that is no better than a C program.
> We have the technology to prevent the need of this Hobson's choice,
> and it's sad not to be able to get any traction with it.

It's because we can't agree on how it should be done! In the GNAT situation you
could have

    pragma Check (Expensive, condition, string)

    pragma Check (Cheap, condition, string)

and then control activation of Cheap or Expensive with e.g.

    pragma Check_Policy (Expensive, Off);
    pragma Check_Policy (Cheap, On);

which seemed to me useful when I implemented it, but in fact we never saw a
customer use this feature, and we never used it ourselves internally, so perhaps
I was mistaken in thinking this a useful idea.

For sure, the artificial attempt to corral cheap stuff into the fold of pragma
Assert, and expensive stuff into the fold of preconditions/postconditions seems
seriously misguided to me!

> Beyond that, I find it incredibly sad that people want to drive Ada
> into a box where it is only useful for large safety-critical
> applications. *All* applications can benefit from this sort of
> technology, but not if it is turned into a difficult formal language
> that only a few high priests can understand. And that's what I'm getting out of this discussion.

Nobody is saying that, it is just that your suggestions here make no technical
sense to some of us. You will have to do a better job of cobnvincing people, or
perhaps decide you are wrong, so far I have not seen any sympathetic response to
the claim that assertions are about cheap debugging stuff, and pre/post
conditions are about expensive contracts.

> Probably you are all right, and there is no real value to the beginner
> and hobbyist anymore, since they can't be monetized. Probably I'd be
> best off stopping thinking for myself and just becoming one of the
> sheep punching a clock. Because the alternative isn't pretty.

That's just not true, we have huge numbers of students in the GAP program
enthusiastically using Ada, and the precondition/postcondition feature is one we
get student questions about all the time (there are also several university
courses focused on programming by contract using the Ada 2012 features).

****************************************************************

From: Yannick Moy
Sent: Thursday, November 24, 2011  3:33 AM

>> We are already WAY beyond this. And there is very real customer
>> demand Have a look at http://www.open-do.org/projects/hi-lite/. There
>> are many large scale users of Ada in safety-critical contexts who are
>> very interested, especially in the environment of 178-C in the extent
>> to which unit proof can replace unit testing.
>
> I looked at the site and didn't see anything concrete, just a lot of
> motherhood statements. I realize that there had to be a lot of that in
> the grant proposals, but I would like to see more than that to feel
> that anything is really being accomplished. How is Hi-Lite going to
> reach its goals.

For something concrete, look at this page, with a small example of Ada 2012 code
whose contracts and absence of run-time errors are proved with our tool (called
gnatprove):

http://www.open-do.org/projects/hi-lite/a-database-example/

How we do it is presented in various papers pointed-to by the main page:
- the high-level view:
http://www.open-do.org/wp-content/uploads/2011/02/DewarSSS2010.doc
- a short introduction:
http://www.open-do.org/wp-content/uploads/2011/06/Hi_Lite_Contract.pdf
- the proof tool-chain:
http://www.open-do.org/wp-content/uploads/2011/06/Why_Hi_Lite_Ada.pdf
- the modified "formal" containers:
http://www.open-do.org/wp-content/uploads/2011/06/Correct_Code_Containing_Containers.pdf

> And clearly, the users requiring 178 and the like are a tiny minority.
> It's perfectly good to support them (they surely need it), but their
> needs are far from the mainstream. As such "Hi-Lite" is just a corner
> of what I want to accomplish.

We are clearly targetting DO-178 users in Hi-Lite, but not only. As an example,
a partner of the project is Astrium, which is in the space industry, where
DO-178 does not apply. And customers who have expressed interest in Hi-Lite come
from a variety of industries.

> (If you don't have big goals, there is no point; and if the
> goals are attainable you probably will end up disappointed. :-) I
> would like to see an environment where all programmers include this
> sort of information in their programs, and all compilers and tools use
> that information to detect (some) bugs immediately.

We agree then! The technology we develop has this potential, because:
* We are not restricting the user in his code. Instead, we detect automatically
  which subprograms we can analyze.
* We don't require any user work upfront. You can start with the default
  implicit contract for subprograms of True for both precondition and
  postcondition! And the effects of subprograms (global variables read/written)
  are generated automatically.
* We don't require an expensive analysis. Each subprogram is analyzed
  separately, based on the contracts of the subprograms it calls.

> That can only be approached incrementally,
> and it requires a grass-roots effort -- it's not going to happen just
> from big projects where management can mandate whatever they want/need.

I don't think Hi-Lite qualifies as a "big project", if you mean by that
something immobile and monolithic. We expect there will be many uses of the
technology, and we will try to accommodate as many as possible. BTW, Hi-Lite is
a very open project, so feel free to participate in technical discussions on
hi-lite-discuss mailing list
(http://lists.forge.open-do.org/mailman/listinfo/hi-lite-discuss), and let us
know if you would like to be involved in any way.

****************************************************************

From: Jean-Pierre Rosen
Sent: Thursday, November 24, 2011  8:06 AM

Let's summarize the positions (correct me if I'm wrong):

The D view:
A program is a whole. If there's a bug in it, it is a bug, irrespectively of
whether it is to be blamed on the caller or the callee. If checks are disabled,
they are disabled as a whole. That's what the important (i.e. paying) customers
-most of them in safety critical applications- want.

The B view:
There are library providers and library users. The library provider is
responsible for his own bugs, and wants to be protected from incorrect calls
from the user. The user must be aware of the right protocol to call the library.
It makes sense to disable checks internal to the library (algorithmic checks),
but not those that enforce the contract with the user. Users are the public at
large, by far the highest number of users, few of them write critical
applications. Not many are paying customers, but this is the public we should
try to conquere.

Personnaly, I understand D, but tend to agree with B. For example, the whole
ASIS interface follows the B model: each query has an "expected element kind",
and I would feel terribly insecure if the checks on the element kind were
removed when I put a pragma to increase the speed on my own program. (Of course,
currently these checks are not implemented as pre-conditions, but they could).

Now, what is the issue? To have one or two pragmas to disable some checks,
either together or separately. Those who want to disable all checks together can
easily do so with two pragmas. Those who want to disconnect the two aspects are
unable to do so if there is only one pragma. Moreover, it's not like a big
change  that could bring nasty consequences all over the language. So I think
there should be really two pragmas, even at this late stage (I even think that
contract violations should have their own, different, exception, but I don't
have much hope to get support on this).

****************************************************************

From: Tullio Vardanega
Sent: Thursday, November 24, 2011  8:24 AM

For what my opinion is worth here, I find JPR's summary useful
for the layman to get to grips with the avalanche of views aired
in this (very interesting) thread.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 24, 2011  8:36 AM

> Now, what is the issue? To have one or two pragmas to disable some
> checks, either together or separately. Those who want to disable all
> checks together can easily do so with two pragmas. Those who want to
> disconnect the two aspects are unable to do so if there is only one
> pragma. Moreover, it's not like a big change  that could bring nasty
> consequences all over the language. So I think there should be really
> two pragmas, even at this late stage (I even think that contract
> violations should have their own, different, exception, but I don't
> have much hope to get support on this).

I strongly object to changing things in an incoimpatible way from the way they
are now. Turning off assertions should turn off all assertions including
preconditions and postconditions.

But I don't have any strong feeling about introducing new gizmos that provide
more control (GNAT already has a far greater level of control than anything that
is likely to be stuffed in at the last minute).

I still overall oppose any change at this stage, we just don't have a clear
consensus for a last minute change. I would say let the market place decide what
level of control is needed.

After all in real life, such control is provided with a mixture of compiler
switches (about which we can say nothing in the RM) and pragmas, and the blance
between them has to be carefully considered in real life.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 24, 2011  8:54 AM

> For what my opinion is worth here, I find JPR's summary useful for the
> layman to get to grips with the avalanche of views aired in this (very
> interesting) thread.

Indeed!

Note that I definitely agree that finer control is needed, and we have
implemented this finer control for years in GNAT (remember that we have
precondition and postcondition pragmas that work in Ada 95 and have been around
for years). So we agree that this kind of control is needed.

My concern is trying to figure out and set in stone what this control should be
at this late stage, when we lack a consensus about what should be done.

In practice you need both compiler switches and appropriate pragmas to control
things. The former (switches) will always be the province of the implementation
anyway. To me it is not so terrible if we have to leave some of the latter up to
the implementor as well.

****************************************************************

From: Robert Dewar
Sent: Thursday, November 24, 2011  9:00 AM

Let me note that Tullio captures the disucssion with Erhardt, but it does not
capture the very different view between Randy and Robert/Tuck, which can be
summarized as follows

Randy thinks pragma Assert is about simple things that have negligible overhead,
and should normally not be suppressed since the overhead is small. But pre/post
conditions are about complex things that may need to be suppressed. That's his
basis for wanting separate control (QUITE different from Erhard's point of view
about standard libraries, which I think we all share). Note that Randy uses the
term "assertions" to apply only to pragma Assert, and does not think of pre/post
as assertions.

Robert and Tuck don't make this big distinction, for them, following Eiffel
thinking, these all come under the heading of assertions, and there is no basis
for separate control *on those grounds*.

The Erhard argument about separate control of Pre and Post(I think this would
include body asserts as well) is quite different and seems valid, though I can't
get too excited, we have this degree of control in GNAT, but we never saw it
used either by a customer or by us ibnternally. But to be fair, we haven't
really seen people use pre/post for general library development (we certainly do
NOT use them yet in our GNAT run-time library).

****************************************************************

From: Erhard Ploedereder
Sent: Friday, November 25, 2011  6:14 AM

I agree 100% with J.P.

We ought to get it right in the standard, not just the implementation, which
later will not budge at all from whatever it implemented initially. Sorry,
Robert, but saying that GNAT already provides fine-grained control and therefore
the standard need not simply does not cut it for me.

Further on the subject:

Hopefully there is an ENABLE option as well as a SUPPRESS, because as a library
writer I have to chooose between:
 a) make it a PRE, which is really good documentation
 b) check it explicitly in the body and raise an exception

If I cannot insist on the PRE-check, I have no choice but to go for b), and I'll
be damned if I then provide the same information as a PRE as well.  I really do
not want to check it twice.

So, having no fine control over PRE is truly bad software-engineering, because
it forces users interested in robust software to do the wrong thing.

****************************************************************

From: Robert Dewar
Sent: Friday, November 25, 2011  8:47 AM

> I agree 100% with J.P.
>
> We ought to get it right in the standard, not just the implementation,
> which later will not budge at all from whatever it implemented
> initially. Sorry, Robert, but saying that GNAT already provides
> fine-grained control and therefore the standard need not simply does
> not cut it for me.

I just think it is too much of a rush to "get this right in the standard", when
there is a wide divergence of opinion on what getting it right means. No one is
disagreeing that a finer level of control would be desirable *in the standard*,
we are just disagreeing over whether there is time for this relatively
non-urgent last minute change given the lack of consensus.

Erhard, make a specific proposal, I think the only chance for a change at this
stage (when you have several people opposed to making a change) is to make a
proposal, then if that proposal gets a consensus we can make the change.

If not, we can continue the discussion process, and then when we come to an
agreement, we just make it recommended practice and existing implementations can
conform right away to the decision. It may well be possible to agree on this so
that a decision is made by the time the standard is official.

> So, having no fine control over PRE is truly bad software-engineering,
> because it forces users interested in robust software to do the wrong thing.

I don't think any users will be forced to do anything they don't like in
practice :-)

****************************************************************

From: Bob Duff
Sent: Friday, November 25, 2011  10:31 AM

> Erhard, make a specific proposal, ...

Right, I've lost track of what is being proposed -- it got buried underneath a
lot of philosophical rambling (much of which I agree with, BTW).  I certainly
agree with Erhard that for a library, one wants a way to turn off "internal"
assertions, but keep checks (such as preconditions) that protect the library
from its clients.

I'm not sure how to accomplish that (e.g., what about preconditions that are
"internal", such as on procedures in a private library package?  What about when
a library calls an externally-visible part of itself?).  And I don't think it's
that big of a problem, because vendors will give their customers what they need.

We can standardize existing practice later (which is really how standards are
supposed to be built, anyway!).

****************************************************************

From: Randy Brukardt
Sent: Monday, November 28, 2011  8:51 PM

> > Erhard, make a specific proposal, ...
>
> Right, I've lost track of what is being proposed -- it got buried
> underneath a lot of philosophical rambling (much of which I agree
> with, BTW).  I certainly agree with Erhard that for a library, one
> wants a way to turn off "internal"
> assertions, but keep checks (such as preconditions) that protect the
> library from its clients.
>
> I'm not sure how to accomplish that (e.g., what about preconditions
> that are "internal", such as on procedures in a private library
> package?  What about when a library calls an externally-visible part
> of itself?).  And I don't think it's that big of a problem, because
> vendors will give their customers what they need.

I don't think that there have really been too many concrete proposals in this
thread - I'll try to rectify that below. But as someone who has supported a
large third-party library that was intended to work on multiple compilers, I
have to disagree with the above statement. In order to create and support
something like Claw, one has to minimize compiler dependencies. It is not likely
that we could have depended on some compiler-specific features unless those are
widely supported.

On top of that, while I agree that vendors will give their *customers* what they
need, that does not necessarily extend to third-party library vendors (which
includes various open source projects as well as paid vendors), as library
creators are not necessarily the customers of the compiler vendors. Library
creators/vendors have a somewhat different set of problems than the typical
customer (need for maximum portability, need to control as much as possible how
the library is compiled, etc.)

So I think it is important that the standard at least try to address these
issues. And it seems silly to claim that it is too hard to do now, given that
this stuff is only implemented in one compiler (that I know of) right now and
that compiler has finer-grained control over these things than anything imagined
as a solution in the Standard. So I can't imagine any significant implementation
or description problems now -- that will get harder as we go down the road and
these things get more widely implemented.

---

Anyway, enough philosophy. Let me turn to some details. Following are several
proposals (most previously discussed), provided in my estimated order of
importance: (note that I try to provide counter-arguments when they have come
up)

Proposal #1: The assertion policy in effect at the point of the declaration of a
    subtype with a predicate is the one used to determine whether it is checked
    or not (rather than the assertion policy at the point of the check, as it is
    currently proposed in the draft Standard).

Reason #1A: It should be possible for the body of a subprogram to be able to
    assume that checks are on for all calls to that subprogram. The rules for
    preconditions (and invariants and postconditions as well) already determine
    whether checks are made by the policy at the point of the subprogram
    declaration, which gives this property. It's weird that predicates are
    different.

Reason #1B: I'm suggesting using the subtype declaration as the determining
    point, as that is similar to that for preconditions. A predicate is a
    subtype property, so having it depend on some unrelated subprogram
    declaration (as Tucker suggested) seems bizarre. And that would require
    having a different determination for predicate checks in other contexts
    (aggregate components, object initializations, etc.) Finally, using the
    subtype declaration should be enough, as a subprogram body always knows the
    location of the subtype declarations used in its parameters profiles.

Rebuttal #1Z: One thing that strikes me about this change is that a body can
    know more about the assertions that apply to the parameters than it can
    about the constraint checks that were made on those same parameters.
    Specifically, if checks are suppressed at a call-site, then random junk can
    be passed into a subprogram -- and there is nothing reasonable that the
    subprogram can do to protect itself. (Rechecking all of constraints of the
    parameters explicitly in the subprogram body is not reasonable, IMHO.) The
    erroneousness caused by such suppression bails us out formally, but that
    doesn't provide any reassurance in practice. The concern addressed above for
    predicates is very similar. However, just because we got it wrong in 1983
    doesn't mean that we have to get it wrong now. So I don't find the suppress
    parallel to be a very interesting argument.

---

Proposal #2: If the invoked subprogram and denoted subprogram of a dispatching
    call have different assertion policies, it is unspecified which is used for
    a class-wide invariant.

Reason #2A: This is fixing a bug; invariants and postconditions should act the
    same and this is the rule used for postconditions (otherwise, the compiler
    would always be required to make checks in the body in case someone might
    turn off the checks elsewhere, not something we want to require).

Reason #2B: I wrote this as applying only to class-wide invariants, as the
    specific invariants only can be determined for the actually invoked
    subprogram (so there is no point in applying them at the call site rather
    than in the body). We could generalize this to cover all invariants, but the
    freedom doesn't seem necessary (and I know "unspecified" scares some users).

Corollary #2C: We need to define the terms "class-wide invariant" and "specific
    invariant", since we keep finding ourselves talking about them and the
    parallel with preconditions (where these are defined terms) makes it even
    more likely that everyone will use them. Best to have a definition.

---

One thing that strikes me is that we seem to have less control over assertions
(including contracts) than we have over constraint checks. One would at least
expect equivalence. Specifically, a subprogram (or entire library) can declare
that it requires constraint checks on (via pragma Unsuppress). It would make
sense to have something similar for libraries to use for assertions. Thus the
next proposal.

Proposal #3: There is a boolean aspect "Always_Check_Assertions" for packages
    and subprograms. If this aspect is True, the assertions that belong to and
    are contained in the indicated unit are checked, no matter what assertion
    policy is specified.

Reason #3A: There ought to be a way for a program unit to declare that it
    requires assertion checks on for proper operation. This ought to include
    individual subprograms. I've described this as an aspect since it applies to
    a program unit (package or subprogram), but a pragma would also work. This
    aspect (along with pragma Unsuppress) would allow a library like Claw to not
    only say in the documentation (that no one ever reads) that turning off
    checks and assertions is not supported, but also to declare that fact to the
    compiler and reader (so checks are in fact not turned off unless some
    non-standard mode is used).

Rebuttal #3Z: One could do this by applying pragma Assertion_Policy(Check) as part of a library. There are four problems with this: first, a configuration pragma only applies to the units with which it actually appears (not necessarily children or subunits
). That means it has to be repeated with every unit of a set. Secondly, since the default assertion policy is implementation-defined, there would be no clear difference between requiring assertions for correct operation and just wanting assertions checked 
(for testing purposes). Third, this requires checking for the entire library (as a configuration pragma cannot be applied to an individual
subprogram, as Suppress and Unsuppress can). That might be too much of a requirement for some uses. Finally, as a configuration pragma, the pragma cannot be part of the library [package] (it has to appear outside). That makes it more likely that it get sep
arated from the unit, and less likely that the requirement be noted by the reader. None of these are compelling by themselves, but as a set it seems to suggest something stronger is needed.

Reason #3C: Having a special assertion policy for this purpose (say
"Always_Check") doesn't seem sufficient because it still has the issues caused by the pragma being a configuration pragma (as noted in the Rebuttal).

---

Proposal #4: Provide an additional assertion policy "Check_External_Only". In
    this policy, Preconditions and Predicates are checked, and others
    (Postconditions, type invariants, and pragma asserts) are ignored.

Reason #4A: The idea here is that once unit testing is completed for a package,
    assertions that are (mostly) about checking the correctness of a body are
    not (necessarily) needed. OTOH, assertions that are (mostly) about checking
    the correctness of calls are needed so long as new calls are being written
    and tested (which is usually so long as the package is in use). So it makes
    sense to treat these separately.

Alternative #4B: I'm not sure I have the right name here, and the name is
    important in this case. My first suggestion was "Check_Pres_Only" which is a
    trick as "Pre"s here means PREconditions and PREdicates. But that could be
    confused with the Pre aspect only, which is not what we want.

Discussion #4C: In the note above, Bob suggests that calls that are fully
    internal ought to be exempted (or something like that). This sounds like FUD
    to me - a strawman set up to prove that since we can't get this separation
    perfect, we shouldn't do it at all.  But that makes little sense to me; at
    worst, there will be extra checks that can't fail, and the user will always
    have the option of turning off all assertion checks if some are left on that
    are intolerable. The proposed rule is simple, and errs on the side of
    leaving checks on that might in fact be internal. It seems good enough
    (don't let best be the enemy of better! :-)

---

My intent is to put all of these on the agenda for the February meeting, unless
of course we have a consensus here that one or more of these are bad ideas.

Finally, I'll mention a couple of other ideas that I won't put forth proposals
for, as I don't think that they will get traction.

Not a proposal #5: Provide an additional assertion policy
    "Check_Contracts_Only". In this policy, pragma Asserts are ignored, and all
    of the others are checked.

The way I view pragma Assert vs. the other contracts, this makes sense. But I
seem to be in the minority on this one, and I have to agree that Proposal #4
makes more sense (except for the lame name), so I am going to support that one
and not push for this.

Not a proposal #6: Have predicate and precondition failures raise a different
    exception, Contract_Error.

This also makes sense in my world view, as failures of such inbound contracts is
a very different kind of error than the failure of a pragma Assert or even a
postcondition in a subprogram body. It would make it much clearer as to whether
the cause of the problem is one within the subprogram or one of the call. But
this feels like a bigger change than any of the first four proposals, we already
have a similar problem with Constraint_Error, and I don't want to go too far
here (I'd rather the easy fixes get accomplished rather than getting bogged down
in the harder ones). If someone else wants to take the lead on this idea, I'll
happily support it.

****************************************************************

From: Brad Moore
Sent: Tuesday, December  6, 2011  12:28 AM

...
> On top of that, while I agree that vendors will give their *customers*
> what they need, that does not necessarily extend to third-party
> library vendors (which includes various open source projects as well
> as paid vendors), as library creators are not necessarily the customers of the compiler vendors.
> Library creators/vendors have a somewhat different set of problems
> than the typical customer (need for maximum portability, need to
> control as much as possible how the library is compiled, etc.)
>
> So I think it is important that the standard at least try to address
> these issues. And it seems silly to claim that it is too hard to do
> now, given that this stuff is only implemented in one compiler (that I
> know of) right now and that compiler has finer-grained control over
> these things than anything imagined as a solution in the Standard. So
> I can't imagine any significant implementation or description problems
> now -- that will get harder as we go down the road and these things get more widely implemented.

I definitely agree with Randy, Erhard, et al, that one needs finer grained
control to do things like enable preconditions while disabling postconditions.

I'm wondering though if we haven't already provided this control in the
language.

One can use statically unevaluated expressions to accomplish this. RM
4.9 (32.1/3 - 33/3)

package Config is
       Expensive_Postconditions_Enabled : constant Boolean := False; end Config;

with Config; use Config;
package Pak1 is

    procedure P
      (Data : in out Array_Type)
       with Pre => Data'First = 0 and then Is_A_Power_Of_Two (Data'Length) ,
                Post =>  Expensive_Postconditions_Enabled and then Correct_Results (Data'Old, Data);

end Pak1;

This already gives programmers tons of flexibility, as I see it, since they can
define as many different combinations of statically unevaluated constant
expressions as needed. One possibly perceived advantage of this approach, is
that it might encourage one to leave the assertion policy enabled, and let the
programmer provide the switches that can be configured for production vs
debugging releases of the application, rather than apply a brute force, all on
or all off approach, or some other such coarser grained policy, which might make
developers/management uneasy, without an exhaustive analysis of all the source.

In spite of these current possibilities though, I think Randy's proposals below
make sense, and are worth pursuing, since it can be desirable to disable/enable
checks without having to modify source code, or implement some sort of
configuration dependent/implementation independent project file approach.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, February 15, 2012  10:50 PM

[Responding to old editorial review comments, the quotes are from Bob Duff.]

> I don't see any problem with 4.6(51/3) and 4.6(57).  "Checks"
> are the things controlled by pragma Suppress.  We decided that
> predicates are controlled by assertion policy, so they can't be
> checks.

That's a *big* problem, because preconditions and the like are most certainly
described as "checks" (see, for example, the Dynamic Semantics section of
6.1.1). And trying to describe them as something else is very difficult (in
terms of wording). The wording of 4.6(51/3) and 4.6(57) is an example of how
confusing this is.

I would prefer to call these things "checks" (because they are), and then exempt
checks controlled by Assertion_Policy (that is, checks caused by assertions)
from Suppress. That shouldn't take many words in 11.5. (Of course, it would be
even better to allow these to be controlled by Suppress as well as
Assertion_Policy. But that seems like more change than we'd like to make now. Of
course, that would provide a solution to the AI05-0290-1 problems of assertion
control, in particular the availability of Unsuppress. But I digress...)

> (I don't entirely agree with that decision, but it's not important.)
> So
> 4.6(51/3) correctly avoids "check" for the predicate.  And
> 4.6(57) correctly says that checks raise P_E or C_E.  An AARM note
> could mention that a predicate failure could raise A_E, but isn't
> mentioned because it isn't a check.

That's what I did for now, but essentially all of the other assertions are
described as checks. It's just too complicated to invent an entire new language
and semantics just for them. If we have to change that, I think we're adding a
month of work to the Standard, because every line of dynamic semantics for
assertions will have to be totally rewritten. And it took us dozens of
iterations to get them right as it is (IF they're right).

> But now I think 4.9(34/3) needs to say:
>
>     The expression is illegal if its evaluation raises an exception.
>     For the purposes of this evaluation, the assertion policy is assumed
>     to be Check.
>
> As I said above, if "evaluation" can happen at compile time, then so
> can "raising".

I'm still dubious, but I think it is irrelevant because assertions are surely
"checks".

Thoughts?

****************************************************************

From: Bob Duff
Sent: Thursday, February 16, 2012  5:18 AM

> That's a *big* problem, ...

Please don't panic!
The only big problem is that the RM is too big.  ;-)

>...because preconditions and the like are most  certainly described as
>"checks" (see, for example, the Dynamic Semantics  section of 6.1.1).

I see.  I didn't realize that, so I wrote the predicates section thinking that
assertions are not checks.  Nobody seemed to care at the time, so let's not get
too excited.  This is what happens when we make the RM too big for one person to
read cover to cover; we have to live with it now.

>...And trying to describe them as something else is very  difficult (in
>terms of wording). The wording of 4.6(51/3) and 4.6(57) is an  example
>of how confusing this is.
>
> I would prefer to call these things "checks" (because they are), and
> then exempt checks controlled by Assertion_Policy (that is, checks
> caused by assertions) from Suppress.

OK, if you think that's easier, I'm all for it.  Certainly assertions are
checks, intuitively speaking.

>...That shouldn't take many words
> in 11.5.

Good.

>...(Of course, it would be even better to allow these to be controlled
>by Suppress as well as Assertion_Policy. But that seems like more
>change  than we'd like to make now. Of course, that would provide a
>solution to the
> AI05-0290-1 problems of assertion control, in particular the
>availability of  Unsuppress. But I digress...)

Yeah, it's a bit of a mess that we have two completely different ways of
suppressing check-like things.  But I agree with not trying to fix that now.

Just yesterday I was discussing a compiler bug with Ed Schonberg, which involved
something like "expand this node with all checks suppressed", and the bug was
that assertions were NOT being suppressed, but they needed to be.

> > (I don't entirely agree with that decision, but it's not important.)
> > So
> > 4.6(51/3) correctly avoids "check" for the predicate.  And
> > 4.6(57) correctly says that checks raise P_E or C_E.  An AARM note
> > could mention that a predicate failure could raise A_E, but isn't
> > mentioned because it isn't a check.
>
> That's what I did for now, but essentially all of the other assertions
> are described as checks. It's just too complicated to invent an entire
> new language and semantics just for them. If we have to change that, I
> think we're adding a month of work to the Standard, because every line
> of dynamic semantics for assertions will have to be totally rewritten.
> And it took us dozens of iterations to get them right as it is (IF they're
< right).

Well, I suppose they're not right, but they're close enough.

> > But now I think 4.9(34/3) needs to say:
> >
> >     The expression is illegal if its evaluation raises an exception.
> >     For the purposes of this evaluation, the assertion policy is assumed
> >     to be Check.
> >
> > As I said above, if "evaluation" can happen at compile time, then so
> > can "raising".
>
> I'm still dubious, but I think it is irrelevant because assertions are
> surely "checks".

OK.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  8:00 AM

I believe (pretty strongly) that Suppress(All_Checks) ought to suppress
assertion checks as well.

****************************************************************

From: Bob Duff
Sent: Thursday, February 16, 2012  8:10 AM

I could be convinced of that, but:

You don't give any reasons for your pretty-strong belief.

We've discussed this, and that's not what we decided.
If we had gone that way, then why would we have invented Assertion_Policy?  It
would make much more sense to have added some new check names.

If we went that way, and the program executes "pragma Assert(False);", and
assertion checks (or all checks) are suppressed, then is it erroneous?

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  8:28 AM

> I could be convinced of that, but:
>
> You don't give any reasons for your pretty-strong belief.

There are a lot of programs that use Suppress(All_Checks) to mean "turn off all
run-time checks" and as we seem to now agree, assertion checks are "checks."

> We've discussed this, and that's not what we decided.

I must have misssed or slept through the discussion on All_Checks as applied to
assertion checks.

> If we had gone that way, then why would we have invented
> Assertion_Policy?  It would make much more sense to have added some
> new check names.

Assertion policy was invented because there was more than just "on" or "off" for
assertions.  We imagined "assume true," "ignore," "check", and "check fiercely,"
etc.

> If we went that way, and the program executes "pragma Assert(False);",
> and assertion checks (or all checks) are suppressed, then is it
> erroneous?

I was in the discussion where we decided that when assertion are ignored, they
are really ignored.  It is as though they weren't there at all.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  8:33 AM

...
> I could be convinced of that, but:
>
> You don't give any reasons for your pretty-strong belief.

The other reason is the wording in 11.5 about All_Checks:

[The following check corresponds to all situations in which any predefined
exception is raised.]

25
All_Checks

Represents the union of all checks; [suppressing All_Checks suppresses all
checks.]

25.a
Ramification: All_Checks includes both language-defined and
implementation-defined checks.

25.b/3
To be honest: {AI05-0005-1} There are additional checks defined in various
Specialized Needs Annexes that are not listed here. Nevertheless, they are
included in All_Checks and named in a Suppress pragma on implementations that
support the relevant annex. Look up "check, language-defined" in the index to
find the complete list.

---

This certainly conveys to me the message that Suppress(All_Checks) suppresses
all checks, whether or not we have a "named" check associated with them.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  1:28 PM

> I believe (pretty strongly) that Suppress(All_Checks) ought to
> suppress assertion checks as well.

This from the guy who insisted up and down that suppression was the wrong model
for assertions. :-)

I actually don't know how to reconcile that with Assertion_Policy(Ignore).
Suppress(All_Checks) makes the program erroneous if checks fail;
Assertion_Policy(Ignore) doesn't.

The cool thing is that if this is true, we only need to add a user Note to 11.5:
"Assertions are checks, so they're suppressed by Suppress(All_Checks). We don't
give them a check name, since using Assertion_Policy is preferred if it is
desired to turn off assertions only." (This is too important for just an AARM
note.)

And reword a few things so that predicates are described as checks.

****************************************************************

From: Bob Duff
Sent: Thursday, February 16, 2012  1:49 PM

> The other reason is the wording in 11.5 about All_Checks:
>
> [The following check corresponds to all situations in which any
> predefined exception is raised.]
>
> Represents the union of all checks; [suppressing All_Checks suppresses
> all checks.]

Assertion_Error is not a predefined exception.  So if you want Suppress to
suppress assertions, we need new wording somewhere.

Most of the above text is @Redundant.  If you want "the union of all checks" to
make sense for assertions, then I think the assertions need check name(s).

And from your other email, I assume you're proposing to change this:

  26  If a given check has been suppressed, and the corresponding error
  situation occurs, the execution of the program is erroneous.

although that wasn't 100% clear to me.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  1:54 PM

> I actually don't know how to reconcile that with Assertion_Policy(Ignore).
> Suppress(All_Checks) makes the program erroneous if checks fail;
> Assertion_Policy(Ignore) doesn't.

Assertion checks are user-specified, and so there is no reason for execution to
become erroneous if they are suppressed, so long as it is interpreted as meaning
the same thing as ignored.  Other kinds of checks, such as array out of bounds,
null pointer, discriminant checks, etc., clearly make the execution erroneous if
they fail and execution proceeds.

Assertion policy was created to allow for more implementation flexibility
through the use of implementation-defined policies.

****************************************************************

From: Steve Baird
Sent: Thursday, February 16, 2012  1:51 PM

>> I believe (pretty strongly) that Suppress(All_Checks) ought to
>> suppress assertion checks as well.
>
> This from the guy who insisted up and down that suppression was the
> wrong model for assertions. :-)

I think this means that we want to make it clear that a suppressing an assertion
check cannot lead to erroneousness in the same way that suppressing other kinds
of checks can.

It doesn't make sense to try to define the behavior of a program execution
which, absent suppression, would have failed an array indexing  check. That's
why such an execution is ,quite correctly, defined to be erroneous.

Assertion checks are different - type-safety and all the other invariants that
an implementation (as opposed to a user) might depend on are not compromised if
we ignore assertion checks. If we say that a suppressed assertion check simply
might or might not be performed, this doesn't lead to definitional problems.

Presumably suppressing an assertion check (when the assertion policy is Check)
means that an implementation is allowed, but not required, to behave as though
the assertion policy in effect is Ignore (which, incidentally, includes
evaluation of the Boolean expression).

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  2:04 PM

> Assertion_Error is not a predefined exception.  So if you want
> Suppress to suppress assertions, we need new wording somewhere.
>
> Most of the above text is @Redundant.  If you want "the union of all
> checks" to make sense for assertions, then I think the assertions need
> check name(s).

I'm not sure I would agree that if something is a "check" then it automatically
needs a "check name."

> And from your other email, I assume you're proposing to change this:
>
>    26  If a given check has been suppressed, and the corresponding error
>    situation occurs, the execution of the program is erroneous.
>
> although that wasn't 100% clear to me.

Yes, as mentioned in an earlier note, suppressing an assertion check would mean
ignoring it, not presuming it was true.

I gave my reasons why I think All_Checks should cover assertion checks.  I'd be
curious how others feel.  When someone says "suppress all" I have always assumed
they really meant it. The creation of Assertion_Policy was to give more
flexibility, but I never thought it meant making "suppress all" mean "suppress
some."  Maybe I am the only person who feels this way...

****************************************************************

From: Edmond Schonberg
Sent: Thursday, February 16, 2012  2:07 PM

> Assertion policy was created to allow for more implementation
> flexibility through the use of implementation-defined policies.

Indeed, but I'm afraid it's not flexible enough because it's a configuration
pragma, while Suppress gives you a per-scope  control.  Could we just make it
into a regular pragma with similar semantics?

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  2:45 PM

...
> > Most of the above text is @Redundant.  If you want "the union of all
> > checks" to make sense for assertions, then I think the assertions
> > need check name(s).
>
> I'm not sure I would agree that if something is a "check"
> then it automatically needs a "check name."

I would hope not, since there are no check names for checks defined in Annexes,
and there is an AARM note (which someone quoted earlier) that says they're
included in All_Checks.

> > And from your other email, I assume you're proposing to change this:
> >
> >    26  If a given check has been suppressed, and the corresponding error
> >    situation occurs, the execution of the program is erroneous.
> >
> > although that wasn't 100% clear to me.
>
> Yes, as mentioned in an earlier note, suppressing an assertion check
> would mean ignoring it, not presuming it was true.

Could you suggest a wording for this paragraph that would have the right effect?

> I gave my reasons why I think All_Checks should cover assertion checks. I'd be
> curious how others feel.  When someone says "suppress all" I have always
> assumed they really meant it. The creation of Assertion_Policy was to give
> more flexibility,
> but I never thought it meant making "suppress all" mean "suppress some."
> Maybe I am the only person who feels this way...

I've always thought that Suppress was a better model than Assertion_Policy for
assertions. I agree that not making them erroneous is probably a good idea. But
I would much prefer that the implementation be allowed to check any assertions
that it wants to, even when they are suppressed. (They're supposed to be true,
after all.) Presumably, an implementation would only check those that it could
then prove to be true or are very cheap. "Ignore" does not let the
implementation have any flexibility in this area.

OTOH, making Suppress(All_Checks) apply to assertions might be a (minor)
compatibility problem. pragma Assert would be included in that, and it probably
isn't included in Ada 2005 compilers. Thus it could be turned off where it is
now on. Not a big deal, but we ought to remain aware of it.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  2:51 PM

>>	Assertion policy was created to allow for more implementation
>>	flexibility through the use of implementation-defined policies.
>>
>	Indeed, but I'm afraid it's not flexible enough because it's a
>configuration pragma, while Suppress gives you a per-scope  control.
> Could we just make it into a regular pragma with similar semantics?

I forgot about that; it had come up in the write-up of AI05-0290-1 I did
yesterday.

If we gave these check names, at least some of the control issues would go away,
because Unsuppress would do what Erhard and I have been asking for (give a way
for a library to force predicate and precondition checks always).

As noted in my previous note, Suppress is better than Ignore because it allows
the compiler to make the check and then depend on it later (presumably it would
only do that if the net code size was smaller). That eliminates some of the need
for other policies.

So perhaps much of what we really want could be accomplished by mostly
abandoning Assertion_Policy, and using Suppress, modulo that it is not erroneous
to fail an unchecked assertion.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  2:58 PM

>>> And from your other email, I assume you're proposing to change this:
>>>
>>>     26  If a given check has been suppressed, and the corresponding error
>>>     situation occurs, the execution of the program is erroneous.
>>>
>>> although that wasn't 100% clear to me.
>>
>> Yes, as mentioned in an earlier note, suppressing an assertion check
>> would mean ignoring it, not presuming it was true.
>
> Could you suggest a wording for this paragraph that would have the
> right effect?

How about:

If a given check has been suppressed, then if it is an assertion check, the
corresponding assertion is simply ignored, while if it is some other check and
the corresponding error situation occurs, the execution of the program is
erroneous.

>> I gave my reasons why I think All_Checks should cover assertion checks. I'd be
>> curious how others feel.  When someone says "suppress all" I have
>> always assumed
>> they really meant it. The creation of Assertion_Policy was to give
>> more flexibility,
>> but I never thought it meant making "suppress all" mean "suppress some."
>> Maybe I am the only person who feels this way...
>
> I've always thought that Suppress was a better model than
> Assertion_Policy for assertions. I agree that not making them
> erroneous is probably a good idea. But I would much prefer that the
> implementation be allowed to check any assertions that it wants to,
> even when they are suppressed. (They're supposed to be true, after
> all.) Presumably, an implementation would only check those that it could then prove to be true or are very cheap. "Ignore"
> does not let the implementation have any flexibility in this area.
>
> OTOH, making Suppress(All_Checks) apply to assertions might be a
> (minor) compatibility problem. pragma Assert would be included in
> that, and it probably isn't included in Ada 2005 compilers. Thus it
> could be turned off where it is now on. Not a big deal, but we ought to remain aware of it.

Pragma Assert was in plenty of Ada 95 compilers as well.
I'd be curious how it was implemented there.  Certainly in Green Hills and Aonix
compilers I can assure you that Suppress(All_Checks) turned off assertion checks
as well.

****************************************************************

From: Steve Baird
Sent: Thursday, February 16, 2012  3:10 PM

> If a given check has been suppressed, then if it is an assertion
> check, the corresponding assertion is simply ignored, while if it is
> some other check and the corresponding error situation occurs, the
> execution of the program is erroneous.

Although I agree with the general direction you are suggesting, I see two minor
problems with this wording.

    1) For Assertion_Policy Ignore, we still evaluate the Boolean.
       I don't think we want something similar but slightly different
       here.

    2) I want to preserve the longstanding rule that suppression only
       gives an implementation additional permissions - it never imposes
       a requirement on an implementation. It sounds like you are
       requiring that the assertion must be ignored, as opposed to
       allowing it to be ignored.

I'll try to come up with wording that addresses these points.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  3:25 PM

>     1) For Assertion_Policy Ignore, we still evaluate the Boolean.
>        I don't think we want something similar but slightly different
>        here.

Huh? When the policy is Ignore, nothing is evaluated. Nor can anything be
assumed. It wouldn't be very useful if it evaluated something.

>     2) I want to preserve the longstanding rule that suppression only
>        gives an implementation additional permissions - it never imposes
>        a requirement on an implementation. It sounds like you are
>        requiring that the assertion must be ignored, as opposed to
>        allowing it to be ignored.

Definitely. I consider that an advantage rather than a "difference".

****************************************************************

From: Tucker Taft
Sent: Thursday, February 16, 2012  3:32 PM

> Although I agree with the general direction you are suggesting, I see
> two minor problems with this wording.
>
> 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
> I don't think we want something similar but slightly different here.

I had forgotten that, and I doubt if all Ada 95 compilers follow that rule, and
it would really defeat the purpose of ignoring the assertion from a performance
point of view. Where is that specified?

> 2) I want to preserve the longstanding rule that suppression only
> gives an implementation additional permissions - it never imposes a
> requirement on an implementation. It sounds like you are requiring
> that the assertion must be ignored, as opposed to allowing it to be
> ignored.

I suppose, but then it must either check or ignore.
It can't suppress the check and then assume it is true.
One of the fundamental principles that got us to the Assertion_Policy approach
was that adding a pragma Assert never made the program *less* safe because it
was asserting something that was in fact untrue.

>
> I'll try to come up with wording that addresses these points.

All power to you.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  3:53 PM

...
> > 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
> > I don't think we want something similar but slightly different here.
>
> I had forgotten that, and I doubt if all Ada 95 compilers follow that
> rule, and it would really defeat the purpose of ignoring the assertion
> from a performance point of view.
> Where is that specified?

I don't think you forgot anything, I think Steve is making this up.

> > 2) I want to preserve the longstanding rule that suppression only
> > gives an implementation additional permissions - it never imposes a
> > requirement on an implementation. It sounds like you are requiring
> > that the assertion must be ignored, as opposed to allowing it to be
> > ignored.
>
> I suppose, but then it must either check or ignore.
> It can't suppress the check and then assume it is true.
> One of the fundamental principles that got us to the Assertion_Policy
> approach was that adding a pragma Assert never made the program *less*
> safe because it was asserting something that was in fact untrue.

Right, this is a general principle in Ada. But of course "check" doesn't mean
that any code will actually be executed: such a check might be optimized out.
For instance:

      procedure P (A : access Something)
          with Pre => A /= null;

Ignoring the fact that the programmer should probably have used a null
exclusion, if a call looks like:

       if Ptr /= null then
            P (Ptr);

The check would also be Ptr /= null. One would expect that normal
common-subexpression and dead code elimination would completely remove the
check. But it still can be assumed true in the body in this case.

****************************************************************

From: Steve Baird
Sent: Thursday, February 16, 2012  3:54 PM

> I'll try to come up with wording that addresses these points.

1) Add Assertion_Check to the list of defined checks (details TBD)

2) Replace "check" with "check other than Assertion_Check" in
    the erroneous execution section of 11.5.

3) In the Implementation Permissions section, add

    At any point within a region for which Assertion_Check
    is suppressed, an implementation is allowed (but not required)
    to define the Assertion_Policy in effect at that point to
    be Ignore.

> Huh? When the policy is Ignore, nothing is evaluated. Nor can anything
> be assumed.

Oops. My mistake.
The RM does contain

    If the assertion policy is Ignore at the point of a pragma Assert,
    ...the elaboration of the pragma consists of evaluating the boolean
    expression ...

but the elided text is significant. My bad.

Nonetheless, I still think that defining the effect of suppression in terms of
the Ignore policy is a good idea.

****************************************************************

From: Bob Duff
Sent: Thursday, February 16, 2012  5:29 PM

> Assertion checks are user-specified, and so there is no reason for
> execution to become erroneous if they are suppressed,...

Not sure what "no reason" means.  Yeah, there is no reason why we MUST define a
suppressed False assertion to be erroneous. But there is a reason that there
ought to be a mode where it's erroneous: efficiency.  Currently, that's done via
an impl-def policy.  There are lots of cases where efficiency can be improved by
assuming (and not checking) that assertions are True.

>...so long as it is interpreted as meaning  the same thing as ignored.

That part is circular reasoning: yes, of course if we define it like "Ignore"
then it's not erroneous.

>...Other kinds of checks,
> such as array out of bounds, null pointer, discriminant  checks, etc.,
>clearly make the execution erroneous if  they fail and execution
>proceeds.

On the flip side, there are non-assertion checks that could sensibly have an
"ignore" option.  Range checks, for example: don't check the range, but don't
later assume it's in range. Overflow checks: don't check, but return an
implementation dependent value of the type.  Robert is fond of pointing out
that:

    pragma Suppress(...);
    if X = 0 then
        Put_Line(...);
    end if;
    Y := 1/X;

most programmers are surprised that the compiler can completely eliminate the if
statement.

> Assertion policy was created to allow for more implementation
> flexibility through the use of implementation-defined policies.

Right, but it's a bit of a mess.
It's not clear why more flexibility isn't desirable for non-assertion checks.

> > The cool thing is that if this is true, we only need to add a user
> > Note to
> > 11.5: "Assertions are checks, so they're suppressed by Suppress(All_Checks).
> > We don't give them a check name, since using Assertion_Policy is
> > preferred if it is desired to turn off assertions only." (This is
> > too important for just an AARM note.)
> >
> > And reword a few things so that predicates are described as checks.

Right, if assertions are checks, we really should be using the standard wording
for checks: "a check is made...".  Currently we say "If the policy is Check,
then ... Assertion_Error is raised", which is weird, because we don't say "if
Divide_Check is not suppressed, a check is made that ... is nonzero".

It would simplify if the assertion-check wording assumed that the policy is
Check.  Then when we define Assertion_Policy, we say, "Wording elsewhere assumes
... Check.  If the policy is Ignore, then instead ...".

I fear we don't have the time to do all this rewording.
Oh, well, it's not the end of the world if we're inconsistent.

> I'm not sure I would agree that if something is a "check" then it
> automatically needs a "check name."

I think the intent was that all checks have names.  But the ones in the annexes
are only named via a "To be honest".  That's a cheat, of course.

> Yes, as mentioned in an earlier note, suppressing an assertion check
> would mean ignoring it, not presuming it was true.

I'm a little uncomfortable with the idea that Suppress wouldn't mean
"erroneous".

I'm a little uncomfortable that:

    subtype S is Natural range 0..10;

has confusingly different semantics than:

    subtype S is Natural with
        Static_Predicate => S <= 10;

> I gave my reasons why I think All_Checks should cover assertion
> checks.  I'd be curious how others feel.

I have mixed feelings.

> ...When someone
> says "suppress all" I have always assumed they really meant it.

Yeah, but to me, "really mean it" means "cross my heart and hope to die, you may
strike me with erroneous lightning if I'm wrong".  In other words, Suppress is
the extreme, "prefer efficiency over safety".

> The creation of Assertion_Policy was to give more flexibility, but I
> never thought it meant making "suppress all" mean "suppress some."
> Maybe I am the only person who feels this way...

I see your point.  Mixed feelings.

> > 1) For Assertion_Policy Ignore, we still evaluate the Boolean.
> > I don't think we want something similar but slightly different here.
>
> I had forgotten that, ...

Please re-forget that.  ;-)

> One of the fundamental principles that got us to the Assertion_Policy
> approach was that adding a pragma Assert never made the program *less*
> safe because it was asserting
  ^^^^^
> something that was in fact untrue.

No, "never" is wrong.  The principle holds for Check and Ignore policies, but
implementations can have a policy where the principle is violated -- and such a
policy has some advantage.

> 1) Add Assertion_Check to the list of defined checks (details TBD)

I'd prefer to split out Precondition_Check, Postcondition_Check,
Predicate_Check, Invariant_Check, Assert_Check (Pragma_Assert_Check?).
Assertion_Check could be the union of these. Predicate_Check could be the union
of Static_Predicate_Check and Dynamic_Predicate_Check.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  6:17 PM

...
> Steve Baird wrote:
> > 1) Add Assertion_Check to the list of defined checks (details TBD)
>
> I'd prefer to split out Precondition_Check, Postcondition_Check,
> Predicate_Check, Invariant_Check, Assert_Check (Pragma_Assert_Check?).
> Assertion_Check could be the union of these.
> Predicate_Check could be the union of Static_Predicate_Check and
> Dynamic_Predicate_Check.

And something like Before_Call_Assertion_Check is the union of Predicate_Check
and Precondition_Check (I don't have the perfect name); and
After_Call_Assertion_Check is the union of Postcondition_Check and
Invariant_Check.

In any case, this is definitely getting into AI05-0290-1 territory ("Improved
control for assertions"), and there is not enough time to come to any
conclusions before the agenda is finalized (that's tomorrow), so I think I'll
probably just add all of this to that AI and we'll have to hash it out at the
meeting.

****************************************************************

From: Bob Duff
Sent: Thursday, February 16, 2012  6:33 PM

> I'll probably just add all of this to that AI and we'll have to hash
> it out at the meeting.

OK.  Or, we can hash it out between 2013 and 2020.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 16, 2012  6:59 PM

> OK.  Or, we can hash it out between 2013 and 2020.

I don't think that works, at least for Suppress(All_Checks), because changing
that later would be a massive incompatibility. (It already might be an
incompatibility, but not with Tucker's compilers.)

Similarly, we've had several strong comments that we need mechanisms for
3rd-party packages. That shouldn't be ignored.

Once we've dealt with those two, it seems inconceivable that we couldn't agree
on the rest (which seems easy to me). In any case, I hope we don't spend the
whole meeting on things that no one will ever notice (this is definitely *not*
in that category).

****************************************************************

From: Erhard  Ploedereder
Sent: Friday, February 17, 2012  3:49 AM

>> I believe (pretty strongly) that Suppress(All_Checks) ought to
>> suppress assertion checks as well.

> The cool thing is that if this is true, we only need to add a user
> Note to
> 11.5: "Assertions are checks, so they're suppressed by Suppress(All_Checks).
> We don't give them a check name, since using Assertion_Policy is
> preferred if it is desired to turn off assertions only." (This is too
> important for just an AARM note.)

And the semantics of
 pragma Unsuppress(All_Checks);
 pragma Assertion_Policy(Ignore);

is what ? Obviously there needs to be a rule to resolve the apparent
contradiction.

Incidently:
The point that "the old checks" prevent erroneousness within the framework of
language semantics while assertion checks are unrelated to erroneousness but
rather deal with application semantics is a very good one. We ought to keep that
in mind when deciding on assertion control.

****************************************************************

From: Jeff Cousins
Sent: Friday, February 17, 2012  4:12 AM

John's book says "pragma Suppress (All_Checks); which does the obvious thing".

So it's not so obvious.

What would people naturally reply if asked what it
covers, without thinking too much? As the Assertion_Policy is called "Check" and
not something like "Verify" my top-of-my-head answer  would be that assertions
are checks.

****************************************************************

From: Erhard Ploedereder
Sent: Friday, February 17, 2012  4:29 AM

>> OK.  Or, we can hash it out between 2013 and 2020.
> I don't think that works, at least for Suppress(All_Checks), because
> changing that later would be a massive incompatibility.

I agree with Randy. This is way too important to not resolve now.
and I want to expand the future incompatibility argument to the Assertion
control in general.

****************************************************************

From: Erhard Ploedereder
Sent: Friday, February 17, 2012  5:06 AM

If pragma Assertion_Policy(Ignore) "guarantees" that the assertion is not
evaluated, then there is no check to be talked about, is there?
Consequently
 pragma Unsuppress(All_Checks);
 pragma Assertion_Policy(Ignore);
would imply that there is nothing there to be unsuppressed, hence Unsuppress
would not be an answer to the 3rd party-SW question.

In the end, I propose to make the Assertion Control pragmas semantically
analogous to the Suppress/Unsuppress pragmas (including the scoping), but
controlling only the assertion world. The syntactic differences are there only
to separate assertion checks from runtime checks that prevent erroneousness.
(Maybe it would be a good idea to have the assertion check names as 2. argument
to assertion control pragmas only, with "All_Checks" as a special comprehensive
choice on the Suppress side.)

****************************************************************

From: John Barnes
Sent: Friday, February 17, 2012  1:26 PM

> John's book says "pragma Suppress (All_Checks); which does the obvious thing".

> So it's not so obvious.

It was obvious when I wrote it!


****************************************************************

From: Tucker Taft
Sent: Saturday, February 25, 2012  10:43 PM

Here is a new version from Erhard and Tuck of an AI on pragma Assertion_Policy.
[This is version /04 of the AI - Editor.]

****************************************************************

From: Randy Brukardt
Sent: Saturday, February 25, 2012  11:08 PM

Comments:

(1) Shouldn't "assertion_kind" be "assertion_aspect_mark"? That is, why use words to
repeat here what is specified in 2.8 and 13.1.1? (Still will need the list of them,
of course.)

(2) Then the wording would be about "assertion aspects" rather than "assertion kinds".

****************************************************************

From: Erhard Ploedereder
Sent: Sunday, February 26, 2012  11:32 AM

Two more places to fix (fairly easily):
4.6. 51/3
6.1.1. 19/3

Apply the boilerplate...
If requires by the <respective> assertion policies in effect at <  > ,

---------------

(I checked for all occurrences of assertion policy in the RM and AARM)

4.9. 34/3 is another, but it is ok as is.

****************************************************************

From: Erhard Ploedereder
Sent: Sunday, February 26, 2012  11:48 AM

Discovery of 19/3 led to a simplification of 31/3 and 35/3 :

modify 6.1.1. 19/3 to read

If required by the Pre, Pre'Class, Post, or Post'Class assertion policies (see
11.4.2) in effect at the point of a corresponding aspect specification
applicable to a given subprogram or entry, then the respective preconditions and
postconditions are considered to be enabled for that subprogram or entry.

Modify 6.1.1 31/3 to:

Upon a call of the subprogram or entry, after evaluating any actual parameters,
checks for enabled preconditions are performed as follows:

Modify 6.1.1. 35/3, first sentence, to:

Upon successful return from a call of the subprogram or entry, prior to copying
back any by-copy in out or out parameters, the check of enabled postconditions
is performed.

****************************************************************

From: Robert Dewar
Sent: Sunday, February 26, 2012  3:48 PM

Query: for run time checks, the implementation can assume that no check is
violated if checks are suppressed.

This is certainly not true for ignoring assertions, a compiler should ignore
assertions if they are off (GNAT at least in one case uses suppressed assertions
to sharpen warning messages, the case is an assert of

   pragma Assert (S'First = 1);

which suppresses warnings about S'First possibly not being 1 even if assertions
are suppressed. But warnings are insignificant semantically, so that's OK.

What about preconditions and postconditions that are suppressed, are they also
required to be totally ignored? Same question with predicates. If predicates are
suppressed, I assume they still operate as expected in controlling loops etc??

Sorry if this is confused!

****************************************************************

From: Erhard Ploedereder
Sent: Monday, February 27, 2012  1:46 AM

...
> What about preconditions and postconditions that are suppressed, are
> they also required to be totally ignored? Same question with
> predicates. If predicates are suppressed, I assume they still operate
> as expected in controlling loops etc??
>
> Sorry if this is confused!

Present thinking is that assertions, pre- and postconditions and type invariants
are ignored in the above sense. Compiler is not allowed to assume truth. I think
that is a pretty solid position.

On subtype predicates the jury is still out. It was written up as "ignored" in
the above sense, but then we discovered some issues; that is the one issue
remaining on the assertion control.

****************************************************************

From: Robert Dewar
Sent: Monday, February 27, 2012  7:20 AM

> Present thinking is that assertions, pre- and postconditions and type
> invariants are ignored in the above sense. Compiler is not allowed to
> assume truth. I think that is a pretty solid position.

I think that makes sense. I am also thinking that perhaps in GNAT we will
implement another setting, which says, assume these are True, but don't generate
run-time code. That's clearly appropriate for things you have proved true.

****************************************************************

From: Tucker Taft
Sent: Monday, February 27, 2012  10:13 AM

> What about preconditions and postconditions that are suppressed, are
> they also required to be totally ignored? Same question with
> predicates. If predicates are suppressed, I assume they still operate
> as expected in controlling loops etc??

Pragma Suppress has no effect on pre/postconditions, except for pragma
Suppress(All_Checks), which *allows* the implementation to interpret it as
Assertion_Policy(Ignore). We intentionally do not want erroneousness to be
associated with assertion-ish things like pre/postconditions, etc. The exact
details of that are part of this AI, and for subtype predicates, are pretty
subtle.  We decided we didn't like the solution currently proposed by this AI
for subtype predicates, but we have agreed on a different approach which still
avoids erroneousness.  I will be writing that up in the next couple of days.

> Sorry if this is confused!

This is a confusing area.  We spent several hours on this topic, and visited
many different places in the design "space."  Personally, I feel pretty good
about where we "landed," but I haven't written it up yet, so you will have to
hang in there for a few more days before you will see the full story, at least
with respect to subtype predicates.  But we all felt it was quite important that
adding assertion-like things to a program and then specifying
Assertion_Policy(Ignore) should *not* introduce erroneousness, even if your
assertion-like things are incorrect.

****************************************************************

From: Steve Baird
Sent: Monday, February 27, 2012  10:42 PM

How does the design you have in mind handle the following example?

     declare
       pragma Assertion_Policy (Ignore);

       subtype Non_Zero is Integer with Static_Predicate
          => Non_Zero /= 0;

       type Rec (D : Non_Zero) is
         record
            case D is
               when Integer'First .. -1 => ...;
               when 1 .. Integer'Last => ....;
            end case;
         end record;

       Zero : Integer := Ident_Int (0);

       X : Rec (D => Zero);

I'm wondering about the general issue of how the Ignore assertion policy
interacts with the coverage rules for case-ish constructs (case statements, case
expressions, variant parts) when the nominal subtype is a static subtype with a
Static_Predicate.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  6:42 AM

> I'm wondering about the general issue of how the Ignore assertion
> policy interacts with the coverage rules for case-ish constructs (case
> statements, case expressions, variant parts) when the nominal subtype
> is a static subtype with a Static_Predicate.

Ignore should only be about removing checks, not altering any of the other
semantics of static predicates, it would not be acceptable at all for ignore to
make a case statement illegal!

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  9:03 AM

>> I'm wondering about the general issue of how the Ignore assertion
>> policy interacts with the coverage rules for case-ish constructs
>> (case statements, case expressions, variant parts) when the nominal
>> subtype is a static subtype with a Static_Predicate.
>
> Ignore should only be about removing checks, not altering any of the
> other semantics of static predicates, it would not be acceptable at
> all for ignore to make a case statement illegal!

Correct.  The intent is "Ignore" means "ignore for the purpose of range checks."
Any non-checking semantics remain, such as membership, full coverage, etc.  Case
statements luckily include an option to raise Constraint_Error at run-time if
the value is not covered for some reason (RM 5.4(13)).  The same is true for
case expressions.  Variant records don't really have such a fall back, but we
will have to be clear that even if Ignore applies where the discriminant subtype
is specified, the subtype's predicate still determines whether or not a
particular discriminant-dependent component exists.  It is as though there were
a "when others => null;" alternative in the variant record, where the "when
others" covers values that don't satisfy the predicate.

I suppose one way to think of it is that values that don't satisfy the predicate
are like values outside of the base range of the subtype.  Some objects of the
subtype can have them, and some objects can't, but the rules of the language
should be set up so that values that don't satisfy the predicate, analogous to
values outside the base range, don't cause erroneousness.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  9:06 AM

...
> I suppose one way to think of it is that values that don't satisfy the
> predicate are like values outside of the base range of the subtype.
> Some objects of the subtype can have them, and some objects can't, but
> the rules of the language should be set up so that values that don't
> satisfy the predicate, analogous to values outside the base range,
> don't cause erroneousness.

That seems exactly right, and for a case statement, it means that just as you do
a range check even if checks are suppressed, you will do a predicate check even
if checks are suppressed.

Interestingly, gnat has a switch -gnatV that forces extra validity checks around
the place. I think these should also trigger extra predicate checks for
predicated subtypes.

****************************************************************

From: Jeff Cousins
Sent: Tuesday, February 28, 2012  9:42 AM

Have we got a definite answer yet as to whether Steve's example

       subtype Non_Zero is Integer with Static_Predicate
          => Non_Zero /= 0;

       type Rec (D : Non_Zero) is
         record
            case D is
               when Integer'First .. -1 => ...;
               when 1 .. Integer'Last => ....;
            end case;
         end record;

(i.e. without coverage of the Zero case) is always legal, always illegal, or
dependent on the Assertion Policy (which is implementation defined if not
specified)?

I could live with either of the first two as long as it's spelt out which.  I
think that before the meeting we would have been evenly split about which we
were expecting.  It seems to have been a mistake to have sold predicates as
being similar to constraints.

****************************************************************

From: Steve Baird
Sent: Tuesday, February 28, 2012  10:02 AM

...
>> I'm wondering about the general issue of how the Ignore assertion
>> policy interacts with the coverage rules for case-ish constructs
>> (case statements, case expressions, variant parts) when the nominal
>> subtype is a static subtype with a Static_Predicate.

> Ignore should only be about removing checks, not altering any of the
> other semantics of static predicates, it would not be acceptable at
> all for ignore to make a case statement illegal!

Agreed.

My question was about dynamic semantics only.

...
> Variant records don't really have
> such a fall back, but we will have to be clear that even if Ignore
> applies where the discriminant subtype is specified, the subtype's
> predicate still determines whether or not a particular
> discriminant-dependent component exists.  It is as though there were a
> "when others => null;" alternative in the variant record, where the
> "when others" covers values that don't satisfy the predicate.

I think this is a bad idea. I think (as in the case of case statements)
Constraint_Error should be raised. Let's detect a problem like this ASAP instead
of sweeping it under the rug and then seeing mystifying behavior later.

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  10:19 AM

> Have we got a definite answer yet as to whether Steve's example
...
> (i.e. without coverage of the Zero case) is always legal, always illegal, or
> dependent on the Assertion Policy (which is implementation defined if not
> specified)?

This is always legal.  Legality should not be affected by the Assertion_Policy.
I will be writing this up shortly.  For case statements, if the case
expression's value doesn't satisfy the static predicate, then Constraint_Error
would be raised, per the existing RM paragram 5.4(13).  For variant records, I
think we have to assume an implicit "when others => null" meaning that if the
discriminant does not satisfy the predicate, the implicit "null" variant
alternative is chosen.

> I could live with either of the first two as long as it's spelt out which.  I
> think that before the meeting we would have been evenly split about which we
> were expecting.  It seems to have been a mistake to have sold predicates as
> being similar to constraints.

Stay tuned for my upcoming write-up.

****************************************************************

From: Bob Duff
Sent: Sunday, February 26, 2012  5:23 PM

> This is certainly not true for ignoring assertions, ...
...
> What about preconditions and postconditions that are suppressed,

Note on terminology: "assertion" is not synonymous with "pragma Assert",
according to the RM.  The term "assertion" includes pragma Assert, and also
predicates, pre, post, and invariants.  I believe this agrees with the usage in
Eiffel.

I think the intent is to treat all assertions, including pre/post, the same way
with respect to your question.  But it's still somewhat up in the air, and there
was some talk during the meeting of treating some kinds of assertions
differently.

****************************************************************

From: Robert Dewar
Sent: Sunday, February 26, 2012  7:01 PM

> Note on terminology: "assertion" is not synonymous with "pragma
> Assert",

great, another case where the RM invents a term that NO Ada programmer will use.
I will bet you anything that to virtually 100% of Ada programmers, assertion
will mean what ever it is that pragma Assert does.

> according to the RM.  The term "assertion" includes pragma Assert, and
> also predicates, pre, post, and invariants.

Why invent inherently confusing terminology

Come up with a new word. Contracts for example or somesuch.

****************************************************************

From: Bob Duff
Sent: Tuesday, February 28, 2012  7:02 AM

> > according to the RM.  The term "assertion" includes pragma Assert,
> > and also predicates, pre, post, and invariants.
>
> Why invent inherently confusing terminology

ARG didn't invent this terminology.  It's pretty standard to include
preconditions and the like in "assertion".

> Come up with a new word. Contracts for example or somesuch.

Ada has too many "new" words as it is.  For example, using "access"
for what everybody else calls "pointer" or "reference" just causes confusion.
We should go along with industry-wide terms, to the extent possible.

"Contract" is an informal term, which to me means a whole set of assertions,
such as all the assertions related to a given abstraction.  Using "contract" to
refer to a particular assertion would confuse things, I think.

****************************************************************

From: Bob Duff
Sent: Tuesday, February 28, 2012  7:18 AM

> ARG didn't invent this terminology.  It's pretty standard to include
> preconditions and the like in "assertion".

By the way, you snipped my reference to Eiffel, which agrees that "assertion"
includes preconditions and the like. Eiffel should be respected when talking
about contracts.

If you still don't believe me, google "assertion programming language".
(Note that the 10'th hit is an AdaCore web page that correctly includes pre,
etc.)

In languages that only have assert statements (C and pre-2012 Ada[1], for
example), that's all you have.  But in languages that have preconditions and
invariants[2], those are included.

[1] Yeah, I know it's a macro in C, and a pragma in Ada, but conceptually, it's
    a statement.

[2] Called "predicates" in Ada.  ;-)

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  7:25 AM

>> Why invent inherently confusing terminology
>
> ARG didn't invent this terminology.  It's pretty standard to include
> preconditions and the like in "assertion".

I mean it's confusing in the Ada context. It is always a mistake to push
terminology that no one will use (e.g.

    a generic package is not a package
    a package spec is not what you think it is
    a type should be called a subtype
    a class type has to be called a tagged type

    and yes, I would add access/pointer to that list.
    etc.)

I am willing to bet that for nearly all Ada programmers Assertion will continue
to refer to things done by pragma Assert, as it always have. And I often see ARG
members using this terminology, e.g. something like

"Well a precondition in a subprogram body is really just an assertion."

which is official nonsense, but everyone understands it!

>> Come up with a new word. Contracts for example or somesuch.
>
> Ada has too many "new" words as it is.  For example, using "access"
> for what everybody else calls "pointer" or "reference" just causes
> confusion.  We should go along with industry-wide terms, to the extent
> possible.
>
> "Contract" is an informal term, which to me means a whole set of
> assertions, such as all the assertions related to a given abstraction.
> Using "contract" to refer to a particular assertion would confuse
> things, I think.

Contract items?

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  7:30 AM

...
> By the way, you snipped my reference to Eiffel, which agrees that
> "assertion" includes preconditions and the like.
> Eiffel should be respected when talking about contracts.

does Eiffel have assertions in the Ada 2005 sense?

The trouble here is that it is so natural to assume that assertion refers to
pragma assert because

a) it has always done so in Ada
b) the name just encourages this identification

That's why I think Ada programmers will continue to use the term assertion to
mean that which is specified with pragma Assert, and it is futile for the ARG to
try to push terminology that won't stick.

More Ada 2012 programmers will know previous versions of Ada than Eiffel!!

****************************************************************

From: Bob Duff
Sent: Tuesday, February 28, 2012  7:45 AM

> does Eiffel have assertions in the Ada 2005 sense?

Yes, but I think it's called "check", so the potential confusion you're worried
about ("assertion" /= "assert") doesn't arise.

By the way, I don't deny that there's a potential confusion.
I usually get around it by saying something like "assertions, such as
preconditions and the like...".

In general, programming language terminology is a mess!
"Procedure", "function", "method", "subroutine", "routine", "subprogram" -- all
mean basically the same thing. It really damages communication among people with
different backgrounds.

Note that the RM often uses the term "remote procedure call" and its
abbreviation "RPC", even though it could be calling a function.  It doesn't make
perfect sense, but RPC is so common in the non-Ada world, we decided to use it.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  7:53 AM

>> does Eiffel have assertions in the Ada 2005 sense?
>
> Yes, but I think it's called "check", so the potential confusion
> you're worried about ("assertion" /= "assert") doesn't arise.

Right, thats what I remembered (no assertions as such).

> By the way, I don't deny that there's a potential confusion.
> I usually get around it by saying something like "assertions, such as
> preconditions and the like...".

Yes, but you can't expect people to do that all the time.
I suppose we should get in the habit of using "asserts"
to refer to the set of things done with pragma assert.
(like preconditions).

****************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, February 28, 2012  8:04 AM

>> "Contract" is an informal term, which to me means a whole set of
>> assertions, such as all the assertions related to a given
>> abstraction.  Using "contract" to refer to a particular assertion
>> would confuse things, I think.
>
> Contract items?

I'd rather avoid "contract", because we often refer to generic formals as a
contract, we talk about the contract model for assume the best/assume the worst,
etc.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  8:08 AM

yes, good point

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, February 28, 2012  10:01 AM

> That's why I think Ada programmers will continue to use the term
> assertion to mean that which is specified with pragma Assert, and it
> is futile for the ARG to try to push terminology that won't stick.

So what is your proposal? We need some word or words to describe the group of
pragma Assert, prcondition, postcondition, type invariant, and maybe subtype
predicate. Repeating them all every time something is said about all of them is
editorial suicide. "Contract" isn't it, since Assert(ions) have no contract
idea.

(By the way, I don't believe that Ada programmers will be so literal in their
interpretations that they believe that only pragma Assert can create
assertions.)

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  10:14 AM

>> That's why I think Ada programmers will continue to use the term
>> assertion to mean that which is specified with pragma Assert, and it
>> is futile for the ARG to try to push terminology that won't stick.
>
> So what is your proposal? We need some word or words to describe the
> group of pragma Assert, prcondition, postcondition, type invariant,
> and maybe subtype predicate. Repeating them all every time something
> is said about all of them is editorial suicide.
> "Contract" isn't it, since Assert(ions) have no contract idea.

At this point I think we need to stick with "assertion expressions"
given that we are using "Assertion_Policy" to control them all, and they all
raise Assertion_Error on failure.

****************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, February 28, 2012  10:19 AM

> So what is your proposal?

Assumptions?

Checks? (I think it's too vague)

****************************************************************

From: Ben Brosgol
Sent: Tuesday, February 28, 2012  10:37 AM

...
> At this point I think we need to stick with "assertion expressions"
> given that we are using "Assertion_Policy" to control them all, and
> they all raise Assertion_Error on failure.

Maybe "assertion forms"?

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  2:38 PM

> (By the way, I don't believe that Ada programmers will be so literal
> in their interpretations that they believe that only pragma Assert can
> create assertions.)

The reason I think this is that this has been the case for years.

****************************************************************

From: Erhard Ploedereder
Sent: Wednesday, February 29, 2012  7:21 AM

> Assumptions?

Has exactly the opposite meaning in verification land, i.e. something that you
can always assume on faith.

> Checks? (I think it's too vague)

Already taken by the run-time checks and, as an axiom, not to be confused with
"the new stuff".

and from Ben B.:
> assertion forms

Does not solve Robert's concern that the term is completely occupied by pragma
Assert.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  2:37 PM

> I could live with either of the first two as long as it's spelt out
> which.  I think that before the meeting we would have been evenly
> split about which we were expecting.  It seems to have been a mistake
> to have sold predicates as being similar to constraints.

To me, if predicates are not similar to constraints they are broken.
The following two should be very similar in effect

    subtype R is integer range 1 .. 10;

    subtype R is integer with
      Static_Predicate => R in 1 .. 10;

****************************************************************

From: Ed Schonberg
Sent: Tuesday, February 28, 2012  2:45 PM

At the meeting there was an agreement in that direction (not unanimous of
course, nothing is).  This is why Assertion_Policy has to have a different
effect on pre/postconditions than on predicate checks. Creating values that
violate the predicate is as bad as creating out-of- range values.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  2:53 PM

The reason I think those two cases have to be very similar (I never like to use
the word equivalent :-)) is that I think in practice any Ada programmer would
expect them to be similar, they sure *look* similar :-)

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  3:01 PM

They are very similar.  The one significant difference is that the first one if
you suppress the range check, your program can go erroneous if you violate the
constraint.  In the second one, if you set Assertion_Policy(Ignore) then some
checks will be eliminated, but there will be no assumption that the checks would
have passed if they had been performed.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  3:24 PM

> They are very similar.  The one significant difference is that the
> first one if you suppress the range check, your program can go
> erroneous if you violate the constraint.

Not easily though, since generally e.g. uninitialized values don't drive you
into erroneousness.

****************************************************************

From: Bob Duff
Sent: Tuesday, February 28, 2012  3:39 PM

> They are very similar.

Agreed.  If you don't turn off the checks, the only difference is which
exception gets raised.  That counts as "very similar" in my book, especially if
you're not going to handle these exceptions (which I expect is the usual case).

If you DO turn off the checks, then you should have made sure by other means
that the checks won't fail, so they're still quite similar.  Of course, you
might make a mistake, and the consequences of that mistake might be different,
but the rule for programmers is simple: Don't do that. That is, don't violate
constraints, and don't violate predicates, and especially don't turn the checks
off without good reason.

****************************************************************

From: Robert Dewar
Sent: Tuesday, February 28, 2012  3:43 PM

> and especially don't turn the checks off without good reason.

Exactly, and deliberately wanting to violate the check without an exception is
NOT a good reason :-)

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  5:07 PM

Here is the "final" version, incorporating the newer ideas about how
Assertion_Policy should apply to subtype predicate checks, and using the term
"enabled" more uniformly.
[Editor's note: This is version /05.]

****************************************************************

From: Steve Baird
Sent: Tuesday, February 28, 2012  6:42 PM

> Here is the "final" version, ..

That's optimistic.

Some questions and observations:

1) In general, I like the approach for defining how
    assertion policies interact with subtype predicates.

    What about cases where a subtype name is repeated with a
    conformance check?

    For example
         pragma Assertion_Policy (Static_Predicate => Check);

         subtype Foo is Integer with Static_Predicate => Foo /= 123;

         package Pkg is
           type T (D : Foo) is private;

           pragma Assertion_Policy (Static_Predicate => Ignore);
         private
           type T (D : Foo) is ....
         end Pkg;

     For a subtype that has a specified predicate aspect
     (either static or dynamic), perhaps we want the
     assertion policy corresponding to that aspect to
     participate in subtype conformance. In the above example,
     the two uses of Foo would fail the subtype conformance
     legality check even though they denote the same subtype.

     Or perhaps we punt and just say that this case is implementation
     dependent.

     Similar issues occur for subprogram declarations (spec, stub,
     and body), and deferred constants.

2) What about conformance for 'Access attributes and related checking?

     We have an access-to-foo type with one assertion policy and an
     aliased object of type foo declared with a different assertion
     policy in effect. Do we want to allow the Access attribute of
     the object to yield a value of the access type?

      Or two access types which would otherwise be convertible but they
      differ with respect to applicable assertion policy. Do we want
      to allow conversion between such access types?

     Maybe allowing these things is ok, but it makes it very hard
     to write assertions that you can count on.

     The same problems occur for access-to-subprogram types.

     Would we want this stricter conformance rule only if the subtype in
     question is affected by the assertion policy? Should two uses
     of Standard,Integer fail a conformance check because of a difference
     in assertion policy? What about the case where we don't know
     (e.g., an access type declaration where the designated type is
      incomplete) or where getting this knowledge requires breaking
      privacy?

      What about overriding primitive subprograms of tagged types?
      Is it ok if overrider and overridden differ with respect to
      assertion policy?

3) For a call with a defaulted expression which includes a
    qualified expression, which assertion policy determines what
    predicate checking is performed for the qualified expression?

4) I think the rules for dealing with assertion policies and generics
    are fine, but I'd still like to see an AARM note stating explicitly
    that an assertion_policy pragma (and, for that matter, a suppress
    pragma) which applies to a region which includes the declaration or
    body of a generic has no effect on an instance of that
    generic (assuming the  instance is declared outside of the region
    affected by the pragma).

    I think the consequences of the rule

      If a pragma Assertion_Policy applies to a generic_instantiation,
      then the pragma Assertion_Policy applies to the entire instance.

    are a bit less obvious than some other rules and an AARM note is
    justified.

****************************************************************

From: Tucker Taft
Sent: Tuesday, February 28, 2012  8:19 PM

...
> For a subtype that has a specified predicate aspect (either static or
> dynamic), perhaps we want the assertion policy corresponding to that
> aspect to participate in subtype conformance. In the above example,
> the two uses of Foo would fail the subtype conformance legality check
> even though they denote the same subtype.
>
> Or perhaps we punt and just say that this case is implementation
> dependent.
>
> Similar issues occur for subprogram declarations (spec, stub, and
> body), and deferred constants.

I think the initial declaration should determine whether the check is enabled.
The state of the assertion policy at the point of the completion should not be
relevant.

> 2) What about conformance for 'Access attributes and related checking?

Yuck.  First we should be sure we agree on the rules without worrying about
Assertion_Policy.  We already decided that "static subtype matching" requires
that predicates come from the same declaration (in 4.9.1(2/3)).  So that seems
pretty clear.

We had hoped that legality didn't depend on Assertion_Policy, but I guess I
would be inclined to say that conflicting Assertion_Policies should cause errors
when using 'Access.

> We have an access-to-foo type with one assertion policy and an aliased
> object of type foo declared with a different assertion policy in
> effect. Do we want to allow the Access attribute of the object to
> yield a value of the access type?
>
> Or two access types which would otherwise be convertible but they
> differ with respect to applicable assertion policy. Do we want to
> allow conversion between such access types?
>
> Maybe allowing these things is ok, but it makes it very hard to write
> assertions that you can count on.
>
> The same problems occur for access-to-subprogram types.

I would go with it being illegal if the predicate-check policies conflict and
there are any subtypes with non-trivial predicates.

Alternatively, for access-to-subprogram, we could try to generalize the
assertion-policy rules for preconditions and postconditions (whatever those are)
for calling through an access-to-subprogram.

> Would we want this stricter conformance rule only if the subtype in
> question is affected by the assertion policy?

I would hope so.  That is, if the predicate is True, then conflicting assertion
policies are not a problem.  It is only if the predicate is not True that the
policies need to agree between the aliased object and the designated subtype of
the access type.  Or equivalently between the designated profile and the
subprogram that is the prefix to the 'Access.

> ... Should two uses
> of Standard,Integer fail a conformance check because of a difference
> in assertion policy? What about the case where we don't know (e.g., an
> access type declaration where the designated type is
> incomplete) or where getting this knowledge requires breaking privacy?

I would need to see some examples there.  I can't quite imagine how that would
happen.

> What about overriding primitive subprograms of tagged types?
> Is it ok if overrider and overridden differ with respect to assertion
> policy?

Here I think in the same way that an overriding subprogram inherits the
convention of the inherited subprogram, the overriding subprogram should
probably inherit the predicate-check assertion policy state.  It is not clear
how else it could work.

> 3) For a call with a defaulted expression which includes a qualified
> expression, which assertion policy determines what predicate checking
> is performed for the qualified expression?

I think the place where the default expression appears.

> 4) I think the rules for dealing with assertion policies and generics
> are fine, but I'd still like to see an AARM note stating explicitly
> that an assertion_policy pragma (and, for that matter, a suppress
> pragma) which applies to a region which includes the declaration or
> body of a generic has no effect on an instance of that generic
> (assuming the instance is declared outside of the region affected by
> the pragma).
>
> I think the consequences of the rule
>
> If a pragma Assertion_Policy applies to a generic_instantiation, then
> the pragma Assertion_Policy applies to the entire instance.
>
> are a bit less obvious than some other rules and an AARM note is
> justified.

Agreed.

****************************************************************

From: Steve Baird
Sent: Wednesday, February 29, 2012  11:35 AM

> I think the initial declaration should determine whether the check is
> enabled.  The state of the assertion policy at the point of the
> completion should not be relevant.

That seems like a good principle.

>> 2) What about conformance for 'Access attributes and related checking?
>
> We had hoped that legality didn't depend on Assertion_Policy, but I
> guess I would be inclined to say that conflicting Assertion_Policies
> should cause errors when using 'Access.

Right. It is as if the same identifier can be used to denote two different
subtypes, one with predicate checking and one not.

I think we *could* allow those two subtypes to conform (i.e., it wouldn't
compromise type-safety), but I agree with you that we probably don't want to.

>> Would we want this stricter conformance rule only if the subtype in
>> question is affected by the assertion policy?
>
> I would hope so.

Me too, but I think we have to deal with the "maybe" case discussed below.

>> ... Should two uses
>> of Standard.Integer fail a conformance check because of a difference
>> in assertion policy? What about the case where we don't know (e.g.,
>> an access type declaration where the designated type is
>> incomplete) or where getting this knowledge requires breaking
>> privacy?
>
> I would need to see some examples there.  I can't quite imagine how
> that would happen.

For example, an access type where the designated type is incomplete (perhaps a
Taft type or a type from a limited view).

     pragma Asserion_Policy (Check);

     procedure P (X : access Some_Incomplete_Type);

     package Nested is
        pragma Assertion_Policy (Ignore);

        type Ref is access procedure (Xx : access Some_Incomplete_Type);

        Ptr : Ref := P'Access; -- legal?

Or, if we are concerned about privacy here (and perhaps we aren't; we could view
assertion_policy stuff as being like repspec stuff, but it would be nicer if we
didn't have to do that):

      package Pkg is
          type Has_A_Predicate is private;
          type Has_no_Predicate is private;
      private
           type Has_A_Predicate is new Integer
             with Static_Predicate => Has_A_Predicate /= 123;

           type Has_No_Predicate is new Integer;
      end Pkg;


      pragma Assertion_Policy (Check);
      use Pkg;
      Has : aliased Has_A_Predicate;
      Has_No : aliased Has_No_Predicate;

      package Nested is
         pragma Assert_Policy (Ignore);
         type Has_Ref is access Has_A_Predicate;
         type Has_No_Ref is access Has_No_Predicate;

         Ptr1 : Has_Ref := Has'Access; -- we want this to be illegal ...
         Ptr2 : Has_No_Ref := Has_No'Access; -- but what about this?


>> What about overriding primitive subprograms of tagged types?
>> Is it ok if overrider and overridden differ with respect to assertion
>> policy?
>
> Here I think in the same way that an overriding subprogram inherits
> the convention of the inherited subprogram, the overriding subprogram
> should probably inherit the predicate-check assertion policy state.
> It is not clear how else it could work.

And if interface types are involved and one subprogram overrides more than one
inherited subp and the inherited guys don't all agree? I think there are also
much more obscure cases not involving interface types where one primitive op can
override two, but I would have to check to be sure.

>> 3) For a call with a defaulted expression which includes a qualified
>> expression, which assertion policy determines what predicate checking
>> is performed for the qualified expression?
>
> I think the place where the default expression appears.

Sounds good. Ditto for all the other forms of default expressions, presumably.

>> Variant records don't really have
>> such a fall back, but we will have to be clear that even if Ignore
>> applies where the discriminant subtype is specified, the subtype's
>> predicate still determines whether or not a particular
>> discriminant-dependent component exists.  It is as though there were
>> a "when others => null;" alternative in the variant record, where the
>> "when others" covers values that don't satisfy the predicate.
>
> I think this is a bad idea. I think (as in the case of case
> statements) Constraint_Error should be raised. Let's detect a problem
> like this ASAP instead of sweeping it under the rug and then seeing
> mystifying behavior later.

Did my "let's treat all case-ish constructs uniformly"
argument change your mind?

****************************************************************

From: Steve Baird
Sent: Wednesday, February 29, 2012  12:05 PM

>> Here I think in the same way that an overriding subprogram inherits
>> the convention of the inherited subprogram, the overriding subprogram
>> should probably inherit the predicate-check assertion policy state.
>> It is not clear how else it could work.
>>
>
> And if interface types are involved ....

Never mind. I see that 3.9.2(10/2) already has

   .... if the operation overrides multiple inherited operations, then
   they shall all have the same convention.

So your proposal already covers this case.


****************************************************************

From: Tucker Taft
Sent: Wednesday, February 29, 2012  12:17 PM

> ... Or, if we are concerned about privacy here (and perhaps we aren't;
> we could view assertion_policy stuff as being like repspec stuff, but
> it would be nicer if we didn't have to do that):

I think conflicting assertion policies is like conflicting rep-clauses.  It has
to see through privacy.  When a programmer starts applying micro-control with
the assertion policy, they are now talking about the concrete representations of
things, not just their abstract interfaces.

...
>> I think this is a bad idea. I think (as in the case of case
>> statements) Constraint_Error should be raised. Let's detect a problem
>> like this ASAP instead of sweeping it under the rug and then seeing
>> mystifying behavior later.
>
> Did my "let's treat all case-ish constructs uniformly"
> argument change your mind?

Not sure, though probably some realistic examples might help decide.  Since
discriminants cannot be changed after an object is created, except by
whole-record assignment, the question is whether we check to be sure the
discriminant is covered by the variant alternatives on object creation or on
component selection, I suppose. Doing it on object creation is perhaps simpler,
so I guess making an unconditional check (even if predicate checks are disabled)
to be sure that some variant alternative covers the discriminant value seems
reasonable. If there is a "when others" then there won't be any check anyway, so
it would only be if the variant part did *not* have a "when others" and relied
on full coverage of exactly those elements that satisfied the static predicate.

So I guess I can go with your suggestion.

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  1:44 PM

Steve,
    Would you be willing to do the next "rev" on this AI?

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  2:20 PM

Sure, but only after I know what ideas we want to express.

In particular, I'm wondering about the interactions with "statically matching" and incomplete types that I mentioned earlier.

I'd like to avoid cases where we conservatively disallow some construct (e.g.,
an access type conversion) because of assertion policy differences when it turns
out that there are no predicate specifications anywhere in the neighborhood.
Maybe we want to be more permissive and assume when dealing with an incomplete
view of a type that the full type has no applicable predicate specifications?
That would make predicates for designated subtypes less trustworthy, but I think
users would be unlikely to accidentally violate a predicate via this mechanism.
Whether it would be used deliberately (the old "designated predicate bypass
trick") is a separate question.

It would be more of a problem that tools, developers, maintainers, etc. would
have to deal with the possibility that someone *might* use this trick, even
nobody ever does.

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  2:31 PM

We could disallow predicates on the first subtype of a type that is a deferred
incomplete type.  Putting predicates on a first subtype seems pretty weird
anyway.  The purpose of a predicate is normally to define an interesting subset,
not to specify something that is true for all values of the type (that would be
more appropriate for a type invariant).

****************************************************************

From: Bob Duff
Sent: Friday, March 2, 2012  2:43 PM

> I'd like to avoid cases where we conservatively disallow some
> construct (e.g., an access type conversion) because of assertion
> policy differences when it turns out that there are no predicate
> specifications anywhere in the neighborhood.

Well, I don't think we want any incompatibilities.

I haven't followed much of this discussion, but if you're suggesting that pragma
Assertion_Policy would affect the legality of a program, I look askance.

****************************************************************

From: Robert Dewar
Sent: Friday, March 2, 2012  2:43 PM

> We could disallow predicates on the first subtype of a type that is a
> deferred incomplete type.  Putting predicates on a first subtype seems
> pretty weird anyway.  The purpose of a predicate is normally to define
> an interesting subset, not to specify something that is true for all
> values of the type (that would be more appropriate for a type
> invariant).

I disagree, it's not weird to have a range on a first subtype

    type R is new integer range 1 .. 10;

so why should it be weird to have a prediate on a first subtype

    type Non_Zero is new Integer with
      Predicate => Non_Zero /= 0;

to me predicates and constraints are really pretty much the same beast, it is
just that predicates have more power. In fact it seems a bit odd to me to have
constraints at all, given a more powerful mechanism that emcompasses ranges, but
of course I understand the historical reasoning.

On the other hand to me deferred incomplete types are a bit weird anyway, so I
really don't mind restrictions on them.

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  2:52 PM

>> We could disallow predicates on the first subtype of a type that is a
>> deferred incomplete type. Putting predicates on a first subtype seems
>> pretty weird anyway. The purpose of a predicate is normally to define
>> an interesting subset, not to specify something that is true for all
>> values of the type (that would be more appropriate for a type
>> invariant).
>
> I disagree, it's not weird to have a range on a first subtype

You are right, if the first subtype is derived from some preexisting type.  But
I believe it would be weird to put a predicate on the first subtype of a
non-private, non-numeric, non-derived type. And if the type is private, a type
invariant is more appropriate.

If the type is numeric or derived, then I can see the use of the predicate on
the first subtype, since you can convert to an un-predicated version using 'Base
if numeric, or by explicit conversion to the parent type if derived.

In any case, it sounds like we agree that imposing restrictions on the use of
predicates with deferred incomplete types would be OK.

****************************************************************

From: Bob Duff
Sent: Friday, March 2, 2012  2:54 PM

> We could disallow predicates on the first subtype of a type that is a
> deferred incomplete type.  Putting predicates on a first subtype seems
> pretty weird anyway.

I don't agree.  I think it makes perfect sense to say:

    type Nonzero is new Integer with Static_Predicate => Nonzero /= 0;

>...The purpose
> of a predicate is normally to define an interesting subset,  not to
>specify something that is true for all values of the  type...

Agreed, specifying a predicate on a scalar first subtype does not say anything
about all values of the type, because 'Base takes away the predicate, as well as
the constraint:

    X: Nonzero'Base := 0; -- no exception

    type Color is (Red, Yellow, Green, None)
        with Static_Predicate => Color /= None;

    subtype Optional_Color is Color'Base; -- allows None

For composites, there's no 'Base, so it applies to all objects of the type
(modulo some loopholes):

    type My_String is array (Positive range <>) of Character
        with Dynamic_Predicate => My_String'First = 1;

Perhaps we should allow 'Base on composites in Ada 2020.

>... (that would be more appropriate for a type invariant).

Well, type invariants only work for private-ish types.

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  3:15 PM

> We could disallow predicates on the first subtype of a type that is a
> deferred incomplete type.

This might be ok for explicit incomplete type declarations.

How does this work with limited withs?

Any type declaration that can be seen via a limited with has an incomplete view.
Fortunately, limited withs don't make subtype declarations visible, so we are
only concerned with first subtypes.

> Putting predicates on
> a first subtype seems pretty weird anyway.  The purpose of a predicate
> is normally to define an interesting subset, not to specify something
> that is true for all values of the type (that would be more
> appropriate for a type invariant).
>

I disagree in the case of a derived type (upon reading Robert's message halfway
through composing this one, I see that he made this point too and you now
agree).

Even in the case of a non-derived type, I could imagine wanting something like

     type Foo (Max_Length : Natural) is
       record
         Data : Buffer(1 .. Max_Length);
         Current_Length : Natural := 0;
       end record
       with Dynamic_Predicate Foo.Current_Length < Foo.Max_Length;

and I wouldn't want to ban this in order to support mixing of assertion
policies.

Another ugly option would be to have a configuration pragma (one which has to be
consistent across the entire partition) for specifying the assertion policy
associated with the designated subtype of an access type when the view of that
subtype is incomplete at the point of the access type definition. Just a
thought. I haven't thought about DSA interactions at all - maybe there aren't
any.

****************************************************************

From: Robert Dewar
Sent: Friday, March 2, 2012  3:30 PM

>      X: Nonzero'Base := 0; -- no exception
>
>      type Color is (Red, Yellow, Green, None)
>          with Static_Predicate =>  Color /= None;
>
>      subtype Optional_Color is Color'Base; -- allows None
>
> For composites, there's no 'Base, so it applies to all objects of the
> type (modulo some loopholes):

Sure, but 'Base for integer types is an odd beast anyway, I virtually never saw
it in user code.

And this is really no different from

   type R is range 1 .. 10;

   R'Base
   range disappeared

****************************************************************

From: Bob Duff
Sent: Friday, March 2, 2012  5:26 PM

> >      X: Nonzero'Base := 0; -- no exception
> >
> >      type Color is (Red, Yellow, Green, None)
> >          with Static_Predicate =>  Color /= None;

I'm not actually sure that's legal.  Is "None" visible here?
Never mind, it's not important to the issues being discussed.

> >      subtype Optional_Color is Color'Base; -- allows None
> >
> > For composites, there's no 'Base, so it applies to all objects of
> > the type (modulo some loopholes):
>
> Sure, but 'Base for integer types is an odd beast anyway, I virtually
> never saw it in user code.

I don't see why it's an "odd beast".  I agree it's not particularly common, but
I sometimes use it.  Like this, for example:

    type Index is range 1..Whatever;
    type My_Array is array(Index range <>) ...;

    subtype Length is Index'Base range 0..Index'Last;

And then use variables of subtype Length to point to the last-used component of
variables of type My_Array.

In Ada 83, you had to declare Length first, and then declare Index in terms of
Length, and that still works, but the above seems better -- the main thing is
the array index, then I add a subtype that "by the way" includes the extra zero
value, in case of empty arrays.

> And this is really no different from
>
>    type R is range 1 .. 10;
>
>    R'Base
>    range disappeared

Not sure what you're trying to say here.  I agree, it's "no different".
The 'Base attribute takes away the predicate, and also takes away the
constraint.  I have no objection to that, and it's occassionally useful. I just
wish 'Base worked for composite types.

My main point was to agree with Tucker that predicates don't apply to all values
of a type, but only to a subset (at least for scalars).

By the way, the more I think about this stuff, the more I agree with those who
have said predicate violations should raise Constraint_Error rather that
Assert_Failure!

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  4:52 PM

>> We could disallow predicates on the first subtype of a type that is a
>> deferred incomplete type.
>
> This might be ok for explicit incomplete type declarations.
>
> How does this work with limited withs?

I don't see a problem with limited withs.
Can you construct an example which has such a problem.

> Any type declaration that can be seen via a limited with has an
> incomplete view. Fortunately, limited withs don't make subtype
> declarations visible, so we are only concerned with first subtypes.
> ...

I don't think we need to restrict predicates on types declared in the visible
part of a package just because they might be referenced in a limited with.  I
couldn't, but perhaps you can construct a problem that involves such a type...

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  5:09 PM

> I don't see a problem with limited withs.
> Can you construct an example which has such a problem.

I haven't tried to compile this, but this should be close.

    package Pkg1 is
      type Even is new Integer with
        Dynamic_Predicate => Even mod 2 = 0;
    end Pkg1;

    limited with Pkg1;
    package Checker is
       pragma Assertion_Policy (Check);
       type Safe_Ref is access all Pkg1.Even;
       Safe_Ptr . Safe_Ref;
    end Checker;

    limited with Pkg1;
    package Ignorer is
       pragma Assertion_Policy (Ignore);
       type Unsafe_Ref is access all Pkg1.Even;
       Unsafe_Ptr . Unsafe_Ref := new Even'(3);
         -- violates predicate, but that's ok
    end Ignorer;

    with Checker, Ignorer;
    use Checker, Ignorer;
    procedure Converter is
        Safe_Ptr_Has_Been_Corrupted;
    begin
        Safe_Ptr := Safe_Ref (Unsafe_Ptr);
        if Safe_Ptr.all not in Even then
           raise Safe_Ptr_Has_Been_Corrupted;
        end if;
    end Converter;

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  5:19 PM

>> I don't see a problem with limited withs.
>> Can you construct an example which has such a problem.
>
> I haven't tried to compile this, but this should be close.

I don't see a problem here, since the compiler can certainly see that there is a
predicate on the type "Pkg1.Even", even if it is using a limited "with" and the
type is officially incomplete.

But I suppose it would be a bigger problem if Even were defined as derived from
some other type declared in a different package, and "Even" didn't have a
predicate itself but it inherited one.  We could keep following the chain of
"with" clauses I suppose just to learn whether the subtypes have predicates, but
once you start doing name resolution you are starting to violate the spirit of
"limited" with.

At this point it looks simpler to disallow the conversion if different assertion
policies apply to the two designated subtypes, even if we don't know for sure
whether there is a predicate.

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  5:24 PM

> But I suppose it would be a bigger problem if Even were defined as
> derived from some other type declared in a different package, and
> "Even" didn't have a predicate itself but it inherited one.  We could
> keep following the chain of "with" clauses I suppose just to learn
> whether the subtypes have predicates, but once you start doing name
> resolution you are starting to violate the spirit of "limited" with.

There would be bigtime implementation problems if we ever introduced a language
rule that required resolution of a name which occurs in a limited view of a
package.

The implementation model is that an implementation should be able to compile a
limited wither after only parsing the limited withee.

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  5:30 PM

> At this point it looks simpler to disallow the conversion if different
> assertion policies apply to the two designated subtypes, even if we
> don't know for sure whether there is a predicate.

Now we are back to undesirable choice B:
   Conservatively disallow otherwise-legal constructs
   because of assertion policy incompatibilities even
   though there are no assertions of any kind in the
   entire program.

This is a point I would like to get consensus on before working on RM wording.

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  5:31 PM

> There would be bigtime implementation problems if we ever introduced a
> language rule that required resolution of a name which occurs in a
> limited view of a package.

Tuck - I didn't mean to suggest that you were advocating such a language rule;
in your message, you had already pointed out that this approach doesn't work in
the general case.

****************************************************************

From: Tucker Taft
Sent: Friday, March 2, 2012  5:40 PM

>> At this point it looks simpler to disallow the conversion if
>> different assertion policies apply to the two designated subtypes,
>> even if we don't know for sure whether there is a predicate.
>
> Now we are back to undesirable choice B:
> Conservatively disallow otherwise-legal constructs because of
> assertion policy incompatibilities even though there are no assertions
> of any kind in the entire program.
>
> This is a point I would like to get consensus on before working on RM
> wording.

Using the term "incompatibility" is a bit misleading... ;-) I would say
"conflicts" so you don't scare anyone.

Anyone who is using conflicting assertion policies but has no assertions of any
kind in the program is asking for trouble, in my mind...

Are we really just worried about conversions between access-to-incomplete types,
or is there a bigger problem here?

****************************************************************

From: Bob Duff
Sent: Friday, March 2, 2012  5:47 PM

> At this point it looks simpler to disallow the conversion if different
> assertion policies apply to the two designated subtypes, even if we
> don't know for sure whether there is a predicate.

So I write a program and debug/test with all-checks-on, as is common practice.
Then I turn some checks off, and it turns illegal?  I don't know what the right
answer is here, but I'm pretty sure this isn't the right answer.

If one turns checks off, and one violates the checks, one should expect bad
things to happen.

> > package Pkg1 is
> > type Even is new Integer with
> > Dynamic_Predicate => Even mod 2 = 0; end Pkg1;
&c

Tuck, your mailer is deleting indentation.  Mailers that molest mail content are
a menace, and should be banished (grumble). But maybe you could just turn that
malfeature off?

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  5:58 PM

> Using the term "incompatibility" is a bit misleading... ;-) I would
> say "conflicts" so you don't scare anyone.
>

Good point.

> Anyone who is using conflicting assertion policies but has no
> assertions of any kind in the program is asking for trouble, in my
> mind...

Yeah, but I was just demonstrating the point with an extreme example. Either
there is a need for varying assertion policies within a partition or there isn't
- if there is, then this problem can arise.

> Are we really just worried about conversions between
> access-to-incomplete types, or is there a bigger problem here?
>

There are variations; P.all'Access is effectively a
type conversion.

I think that what it really comes down to is the
definition of "statically matching" for subtypes;
to see where the problems are, look where that is
used. As your question suggests, I think we can
dismiss RM uses of "statically matching" that cannot
involve an incomplete type.

There was also the issue that determining whether a
private type has a specified predicate breaks privacy,
but we know how to implement that (and, if you think
of predicates as being similar to constraints, then
it seems reasonable to treat a predicate spec as being
just another kind of rep spec).

****************************************************************

From: Bob Duff
Sent: Friday, March 2, 2012  5:59 PM

> Using the term "incompatibility" is a bit misleading... ;-) I would
> say "conflicts" so you don't scare anyone.

Right.  But are you sure there no real incompatibilities
(2005-2012) here?  Say a program contains pragmas Assert, no other assertions,
and contains pragmas Assertion_Policy. It seems like you're wanting to add an
assume-the-worst rule just-in-case there are predicates, which there aren't.
Isn't that incompatible?

I hope I have the sense to butt out of this conversation soon!

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  6:09 PM

I agree with both of you, but mostly Tuck.

Tuck was referring to my use of the word "incompatibility" in talking about
about a single partition where the entire partition did not share the same
assertion policy.

Bob is raising the point that there is an incompatibility here in the usual
sense (we reject a program that used to compile), but Tuck was correct that I
was not talking about that kind of incompatibility when I used the term.

****************************************************************

From: Steve Baird
Sent: Friday, March 2, 2012  6:38 PM

> Now we are back to undesirable choice B:
>   Conservatively disallow otherwise-legal constructs
>   because of assertion policy incompatibilities even
>   though there are no assertions of any kind in the
>   entire program.
>
> This is a point I would like to get consensus on before working on RM
> wording.

I suppose that if I'm going to talk about choice B and request a consensus, then
I ought to also present a choice A.

We could simply ignore assertion policy in deciding whether two names denoting
the same subtype denote statically matching subtypes and then say that in cases
where a stricter conformance check along the lines of the stuff we have been
discussing today would have flagged a problem, users instead get
implementation-dependent assertion enforcement. Or perhaps we could even define
some portable rules for resolving these assertion-policy conflicts.

This would be a simpler model, but it would make predicates easier to violate
(and might introduce portability issues).

****************************************************************

From: Erhard Ploedereder
Sent: Saturday, March 3, 2012  12:44 PM

> Now we are back to undesirable choice B:
>   Conservatively disallow otherwise-legal constructs
>   because of assertion policy incompatibilities even
>   though there are no assertions of any kind in the
>   entire program.

I find this not just undesirable; it is close to unacceptable.

Why is there no further discussion on treating subtype predicates in the
constraints/checks/suppressable category rather than the assertion/ignorable
category?

If the main point of resistance is that predicate checks unlike constraint
checks are not to be assumed to be "true" when suppressed, than this rule can be
easily stated as such. It would certainly be a rule far preferable to the rules
that are being discussed currently.

It also would automatically allow for Steve's proposal phrased as "...users
instead get implementation-dependent assertion enforcement"

If "erroneousness by suppressing" is the issue, well (apart from my opinion that
it is indeed erroneous to ignore a failed subtype predicate), then one could
probably also describe it as a bounded error to create an invalid value by
ignoring/suppressing the failed check or limit the suppressing in Steve's sense.

****************************************************************

From: Tucker Taft
Sent: Saturday, March 3, 2012  1:05 PM

> ... If the main point of resistance is that predicate checks unlike
> constraint checks are not to be assumed to be "true" when suppressed,
> than this rule can be easily stated as such. It would certainly be a
> rule far preferable to the rules that are being discussed currently.

This would mean that the compiler could never trust a predicate on a subprogram
parameter, on a global variable, on a dereferenced object, etc.  That would seem
to imply a lot of overhead.

If the only issue is conversion between access-to-incomplete types, I am
reluctant to give up everything else just for those.

****************************************************************

From: Robert Dewar
Sent: Saturday, March 3, 2012  1:50 PM

> Why is there no further discussion on treating subtype predicates in
> the constraints/checks/suppressable category rather than the
> assertion/ignorable category?

I am in favor of this, I think trying to ignore predicates makes no sense.

> If the main point of resistance is that predicate checks unlike
> constraint checks are not to be assumed to be "true" when suppressed,
> than this rule can be easily stated as such. It would certainly be a
> rule far preferable to the rules that are being discussed currently.
>
> It also would automatically allow for Steve's proposal phrased as
> "...users instead get implementation-dependent assertion enforcement"
>
> If "erroneousness by suppressing" is the issue, well (apart from my
> opinion that it is indeed erroneous to ignore a failed subtype
> predicate), then one could probably also describe it as a bounded
> error to create an invalid value by ignoring/suppressing the failed
> check or limit the suppressing in Steve's sense.

I really don't mind failed predicates being just as bad as failed constraints
(any differentiation between the two seems hard to explain and plain odd).

****************************************************************

From: Robert Dewar
Sent: Saturday, March 3, 2012  1:51 PM

> This would mean that the compiler could never trust a predicate on a
> subprogram parameter, on a global variable, on a dereferenced object,
> etc.  That would seem to imply a lot of overhead.

I think the compiler should be allowed to trust predicates exactly to the same
extent it is allowed to trust constraints, no more, and no less.

****************************************************************

From: Tucker Taft
Sent: Saturday, March 3, 2012  2:16 PM

>> Why is there no further discussion on treating subtype predicates in
>> the constraints/checks/suppressable category rather than the
>> assertion/ignorable category?
>
> I am in favor of this, I think trying to ignore predicates makes no
> sense.
  ...

If we go this route, then I would be in favor of the suggestion that predicate
checks raise Constraint_Error on failure, and we treat them as similarly to
constraints in every way.  That is, assign them their own "_Check" identifier
and have them controlled by pragma Suppress/Unsuppress.

I agree that the more we talk about them, the more they resemble subtype
constraints, and trying to give them the same "pampering" we give the other
assertion-like things doesn't seem to be working.

****************************************************************

From: Bob Duff
Sent: Saturday, March 3, 2012  2:33 PM

> I think the compiler should be allowed to trust predicates exactly to
> the same extent it is allowed to trust constraints, no more, and no
> less.

I agree.  And they should raise Constraint_Error on failure, as for constraints
and "not null".

****************************************************************

From: Robert Dewar
Sent: Saturday, March 3, 2012  2:33 PM

>> I am in favor of this, I think trying to ignore predicates makes no
>> sense.
>    ...
>
> If we go this route, then I would be in favor of the suggestion that
> predicate checks raise Constraint_Error on failure, and we treat them
> as similarly to constraints in every way.  That is, assign them their
> own "_Check" identifier and have them controlled by pragma
> Suppress/Unsuppress.

I agree 100% with this proposal

> I agree that the more we talk about them, the more they resemble
> subtype constraints, and trying to give them the same "pampering" we
> give the other assertion-like things doesn't seem to be working.

I think it is just confusing to try to distinguish them from subtype
constraints.

****************************************************************

From: Robert Dewar
Sent: Saturday, March 3, 2012  2:34 PM

> I agree that the more we talk about them, the more they resemble
> subtype constraints, and trying to give them the same "pampering" we
> give the other assertion-like things doesn't seem to be working.

Maybe they should be called Constraint instead of Predicate (half kidding :-))

****************************************************************

From: Erhard Ploedereder
Sent: Saturday, March 3, 2012  4:39 PM

> If we go this route, then I would be in favor of the suggestion that
> predicate checks raise Constraint_Error on failure, and we treat them
> as similarly to constraints in every way.  That is, assign them their
> own "_Check" identifier and have them controlled by pragma
> Suppress/Unsuppress.

That is exactly the notion that I would like to see explored more.
Intuitively, it seems "right". But I am waiting for Steve's "have you considered
... ?".

****************************************************************

From: Randy Brukardt
Sent: Sunday, March 4, 2012  6:53 PM

> That is exactly the notion that I would like to see explored more.
> Intuitively, it seems "right". But I am waiting for Steve's "have you
> considered ... ?".

I'm not Steve, but have you considered ;-) that Suppress eliminates checks based
on their location, while assertions (contract if you prefer) eliminate checks
based on the declaration?

This works for constraints only because any check that would fail (but is not
detected by a suppressed check) makes the program erroneous. In that case, the
fact that the body of the subprogram is "wrong" (assumes that the check is made)
is OK (the program makes no sense anyway). (Arguably, this is not the way
Suppress was really intended to work, as evidenced by the "On" parameter to the
Suppress pragma, but it never was properly defined.)

But there never has been any support for making predicates (or any other
assertions) cause erroneous execution in this way. (The idea being that adding a
predicate should never make a program less safe, in any language-defined mode.)

That means that if you have location-based Suppress, then you cannot use
predicates to move correctness checks into the contract rather than in the body.
When the check state is ignore at some call site, you neither get a check nor
erroneous execution if that check fails. Thus you have to repeat the check in
the body (and moreover, the compiler can almost never optimize the duplicate
check away). OTOH, preconditions work "right", so the net effect is that you
always have to use a precondition rather than a predicate (which is usually
going to be more complicated and less readable). That would strip away a large
part of their value.

Erhard, you have been as concerned about this as I have, so I don't understand
why you're willing to abandon it now.

****************************************************************

From: Robert Dewar
Sent: Sunday, March 4, 2012  7:07 PM

...
> But there never has been any support for making predicates (or any other
> assertions) cause erroneous execution in this way. (The idea being
> that adding a predicate should never make a program less safe, in any
> language-defined mode.)

I understand the idea, but the fact of the matter is it just doesn't work to
somehow thing of predicates as something that makes the program safer. They
really fundamentally change the meaning of the program, just as constraints do.
Any attempt at distinguishing them from constraints is IMO doomed to end up in a
mess.

> Erhard, you have been as concerned about this as I have, so I don't
> understand why you're willing to abandon it now.

I do!

****************************************************************

From: Randy Brukardt
Sent: Sunday, March 4, 2012  7:09 PM

...
> We could simply ignore assertion policy in deciding whether two names
> denoting the same subtype denote statically matching subtypes and then
> say that in cases where a stricter conformance check along the lines
> of the stuff we have been discussing today would have flagged a
> problem, users instead get implementation-dependent assertion
> enforcement. Or perhaps we could even define some portable rules for
> resolving these assertion-policy conflicts.

It's pretty clear that the "default" should be "Check"; that is, if there is any
"conflict", "Check" always wins. Everybody has to see "Ignore" before we ignore
anything.

But I have to admit, this doesn't seem to be working.

What I don't understand (or perhaps remember) is what was so bad about the
"simple" model that the policy that applies to the predicate is what applies to
the check? The way Tucker wrote that model up during the meeting didn't work,
but that was a terminology problem rather than any real definitional problem.
That model avoids problems with static matching (because the subtypes that match
are identical to the policies applied), it doesn't assign a meaning to
"renaming" subtypes (which bothered people about some other models).

It works properly for contracts (so long as you are careful), it doesn't cause
these definitional problems, and it doesn't introduce erroneousness. So what
have I missed??

****************************************************************

From: Randy Brukardt
Sent: Sunday, March 4, 2012  7:47 PM

> I understand the idea, but the fact of the matter is it just doesn't
> work to somehow thing of predicates as something that makes the
> program safer. They really fundamentally change the meaning of the
> program, just as constraints do. Any attempt at distinguishing them
> from constraints is IMO doomed to end up in a mess.

I tried to make a point like this last fall, and was essentially told I was
crazy. Apparently, it is only crazy if I try to explain it...sigh.

Anyway, I don't disagree with your point, but it is important to realize that
anything that is true about predicates is also true about preconditions. That
is, some specifications have to be given in precondition form (because they
involve multiple parameters), but other specifications can be given in either
predicate or precondition (or constraint for that matter) forms. It is
uncomfortable for those to be handled differently.

And I don't want something a client does to introduce errors (or
erroneousness) into my code - no matter how I describe the contract.

(I can show examples of all of these cases using the Ada.Containers as a basis,
if you need examples of what I'm talking about.)

One of the appealing things about predicates is that they (appear) to offer a
way to avoid the bugs caused by client suppression of constraint checks. Using
an assertion model, I'd definitely consider eliminating almost all of the
constraints from my program. If we use a Suppression model for predicates but
not preconditions, then that will force everything into preconditions.

Let me make it clear that virtually any model would be preferable to the one
Tucker and Steve seem to be describing. So I could imagine following a purely
suppression model for predicates if we can't work out something better. But I'm
very dubious that there was any problem with the "policy at the point of
predicate declaration" model.

****************************************************************

From: Robert Dewar
Sent: Sunday, March 4, 2012  7:59 PM

> Anyway, I don't disagree with your point, but it is important to
> realize that anything that is true about predicates is also true about
> preconditions. That is, some specifications have to be given in
> precondition form (because they involve multiple parameters), but
> other specifications can be given in either predicate or precondition
> (or constraint for that
> matter) forms. It is uncomfortable for those to be handled differently.

I do not think of predicates this way at all, I think of them just as
constraints, trying to convolute them with preconditions is to me confusing
obfuscation.

****************************************************************

From: Randy Brukardt
Sent: Sunday, March 4, 2012  8:21 PM

That makes sense for static predicates and some other predicates. But keep in
mind that constraints themselves are a replacement for preconditions (for
instance, if you use a Positive parameter, you don't usually include that the
parameter is positive as part of the precondition - but it surely is).

And certainly some dynamic predicates would exist only for the purpose of
simplifying preconditions in this way. For instance, if you had:

     subtype Valid_Root_Window_Type is Root_Window_Type
         with Dynamic_Predicate => Is_Valid (Valid_Root_Window_Type);

in Claw, you could use it on most of the operations to eliminate having to
mention this in (almost) every precondition. It would be preferable because the
name of the subtype would serve as a reminder of the requirement (it wouldn't be
necessary to read the precondition).

If predicates work differently than preconditions, then 3rd-party developers
(and the Standard itself) can really only use preconditions for this sort of
thing (or at least have a strong incentive to do so), and that will clutter and
lengthen the preconditions a lot. Bob has said that he uses predicates almost
exclusively for this sort of thing, so it is not just me thinking this way. (Not
to put thoughts into Bob's mouth though - I don't know if he cares about how
assertion policy works at all.)

****************************************************************

From: Bob Duff
Sent: Sunday, March 4, 2012  8:40 PM

>...Bob has said that he uses predicates  almost exclusively for this
>sort of thing, so it is not just me thinking  this way.

Yes.  In many cases, at first I think I need a precondition, and then I see that
the same precondition applies to many procedures, and it's a property of a
single parameter, so I switch to a predicate.  And then I can use it for local
variables, components, etc.  Good.

The only time I really need a precondition is when it refers to two or more
parameters.  Other times, predicates usually seem better.  For DRY if nothing
else.

>...(Not to put thoughts into Bob's mouth though - I don't know if he
>cares about how assertion policy works at all.)

I care, but I've come to the conclusion that it doesn't much matter what the
Standard says.  Implementations will do what their customers want.  I think we
can safely let the market decide, in this case.

****************************************************************

From: Robert Dewar
Sent: Sunday, March 4, 2012  8:46 PM

> Yes.  In many cases, at first I think I need a precondition, and then
> I see that the same precondition applies to many procedures, and it's
> a property of a single parameter, so I switch to a predicate.  And
> then I can use it for local variables, components, etc.  Good.
>
> The only time I really need a precondition is when it refers to two or
> more parameters.  Other times, predicates usually seem better.  For
> DRY if nothing else.

Well the above are incompatible observations to me.

You say in the first para that a predicate is appropriate if it applies to many
procedures. But if you have a precondition that applies to a single parameter
for a single procedure, it ends up being heavier to use a predicate, since it
requires you to declare a special subtype just for that procedure call.

****************************************************************

From: Jeff Cousins
Sent: Monday, March 5, 2012  5:30 AM

Speaking as a poor old user I agree with Robert, predicates are a lot easy to
understand if they work like constraints and are suppressed like constraints.
Predicates have been "sold" as being a cleverer form of constraints, and it's
confusing if they sit in a fuzzy area half way between constraints and
assertions.

There is Randy's problem that you cannot use predicates to move correctness
checks into the contract rather than in the body, but as this problem already
exists for constraints I think it should be solved in a common way, say a pragma
or aspect "suppress_determined_at_call_site_not_body" in the spec.

****************************************************************

From: Robert Dewar
Sent: Monday, March 5, 2012  5:48 AM

I think people are worrying too much about the detailed issue of what happens
when suppressed checks fail.

For preconditions and postconditions, I think it is just fine for these to be
totally ignored if suppressed, like assertions (sorry can't help using this term
in its obvious sense, i.e. stuff done with pragma assert).

But predicates really do read like constraints (and BTW I think
*should* raise constraint error if they fail).

"poor old users" have the following pretty simple view of constraints.

You leave checks on unless you are absolutely sure that the checks won't fail,
and you really need the extra performance. Then, if and only if these two
factors are true, you suppress checks.

The issue of exactly what happens if checks fail when they are suppressed is
something that only language lawyers know for constraints, and that will
continue to be true for predicates no matter what we decide, users simply won't
know the rules (and won't think that they have to, because they will only
suppress checks when they are sure they won't fail).

****************************************************************

From: Jeff Cousins
Sent: Monday, March 5, 2012  5:56 AM

Yes to all that.

****************************************************************

From: Erhard Ploedereder
Sent: Monday, March 5, 2012  7:22 AM

> That means that if you have location-based Suppress, then you cannot
> use predicates to move correctness checks into the contract rather
> than in the body. When the check state is ignore at some call site,
> you neither get a check nor erroneous execution if that check fails.
> Thus you have to repeat the check in the body (and moreover, the
> compiler can almost never optimize the duplicate check away). OTOH,
> preconditions work "right", so the net effect is that you always have
> to use a precondition rather than a predicate (which is usually going to be more complicated and less readable).
> Erhard, you have been as concerned about this as I have, so I don't
> understand why you're willing to abandon it now.

Correct, but arguably this is not such a bad move. To use subtype predicates for
that purpose, one needs to introduce a subtype, which either clutters up the
interface (if it is part of the interface) or the predicate is not visible as
part of a contract (if it is part of the body of the interface). I don't see why
PRE does not cover the necessary grounds for this.

> I'm not Steve, but have you considered  that Suppress eliminates
> checks based on their location, while assertions (contract if you
> prefer) eliminate checks based on the declaration?> This works for
> constraints only because any check that would fail (but is not
> detected by a suppressed check) makes the program erroneous.

The erroneousness I am willing to accept. The Suppress semantics for subtype
predicates could be made different than for constraints, as far as I am
concerned to maintain value-safeness, i.e. wahtever applied to the aspect
specficiation appplies to all checks of the aspect.

****************************************************************

From: Tucker Taft
Sent: Monday, March 5, 2012  9:43 AM

> It works properly for contracts (so long as you are careful), it
> doesn't cause these definitional problems, and it doesn't introduce erroneousness.
> So what have I missed??

You have to have two different predicates, one which is used for checking, and
one which is used for membership. Or I suppose you could say is what matters is
the Assertion_Policy at the point of the "last" explicit aspect specification
for a predicate.  That means if you want to change whether a given predicate
check is enabled, you have to write

   ... with Static_Predicate => True;

at a point where you have specified a different Assertion_Policy.

That could probably work, as you would be unlikely to do that by mistake.

****************************************************************

From: Geert Bosch
Sent: Monday, March 5, 2012  1:16 PM

> If we go this route, then I would be in favor of the suggestion that
> predicate checks raise Constraint_Error on failure, and we treat them
> as similarly to constraints in every way.  That is, assign them their
> own "_Check" identifier and have them controlled by pragma
> Suppress/Unsuppress.
>
> I agree that the more we talk about them, the more they resemble
> subtype constraints, and trying to give them the same "pampering" we
> give the other assertion-like things doesn't seem to be working.

Right, I agree with this. Anything else is just too complicated for users to
grasp and for us to properly define.

****************************************************************

From: Randy Brukardt
Sent: Monday, March 5, 2012  6:25 PM

> > It works properly for contracts (so long as you are careful), it
> > doesn't cause these definitional problems, and it doesn't introduce
> > erroneousness. So what have I missed??
>
> You have to have two different predicates, one which is used for
> checking, and one which is used for membership.

Yes, but that seems necessary in any model (including Suppression). Since
predicates are always used in memberships, validity checks, and case/loop
statements (irrespective of the Assertion_Policy), and all subtypes have
predicates, there are always going to be two predicates associated with every
subtype (the "full" predicate and the one that depends on the assertion policy).
The only reason you can get away with a single constraint is that only the last
constraint is used (it's always a proper subset or fails a check); that model
does not work for predicates.

> Or I suppose you could say is what matters is the Assertion_Policy at
> the point of the "last" explicit aspect specification for a predicate.
> That means if you want to change whether a given predicate check is
> enabled, you have to write
>
>    ... with Static_Predicate => True;
>
> at a point where you have specified a different Assertion_Policy.
>
> That could probably work, as you would be unlikely to do that by
> mistake.

I'm not sure this helps much; you've still got two predicates for every subtype.
And it makes subtype predicates subtly different than preconditions (which would
be the point of using this model - to make them work the same). Preconditions
inherit the checking state from parent operations.

Anyway, we have to find a proper model here, and soon, as this is the last
remaining Ada 2012 issue and we've promised an almost-final standard for review
ASAP.

Also note that changing predicates to a suppression model would also imply no
longer classifying them as "assertions". (I cannot imagine how we could still
call them "assertions" but yet treat them differently in every important
[user-visible] way - not affected by assertion_policy, erroneous rather than
ignore, etc.) This would totally destroy our carefully-crafted wording, which
would have to be completely done over from scratch. Indeed, that also includes
the bounded error rules for protected actions among other things.

Predicates are more like assertions for most purposes (since arbitrary
expressions evaluated at arbitrary points have far more "issues" than the much
more restricted possibilities of constraints). We need (almost) all of the rules
that apply to assertions (including preconditions, etc.) to apply to them as
well.

Since assertions (general name) are the most important thing about Ada 2012, it
appears that we have two unappealing choices:
(1) Go forward with rules we *know* are wrong, assuming implementers will clean
    up the mess (with the complete loss of portability that entails); or
(2) Abandon Ada 2012 altogether, restarting it whenever we figure this stuff out
    to true agreement (essentially making it Ada 2014).

Blah.

****************************************************************

From: Robert Dewar
Sent: Monday, March 5, 2012  6:50 PM

> Also note that changing predicates to a suppression model would also
> imply no longer classifying them as "assertions". (I cannot imagine
> how we could still call them "assertions" but yet treat them
> differently in every important [user-visible] way - not affected by
> assertion_policy, erroneous rather than ignore, etc.) This would
> totally destroy our carefully-crafted wording, which would have to be
> completely done over from scratch. Indeed, that also includes the
> bounded error rules for protected actions among other things.

Right, indeed I think we should NOT call predicates assertions, it's confusing.

> Predicates are more like assertions for most purposes (since arbitrary
> expressions evaluated at arbitrary points have far more "issues" than
> the much more restricted possibilities of constraints). We need
> (almost) all of the rules that apply to assertions (including
> preconditions, etc.) to apply to them as well.

Well they may be more like assertions from a detailed legalistic semantic point
of view, but the fact remains that they are like constraints from the
programmers point of view

> Since assertions (general name) are the most important thing about Ada
> 2012, it appears that we have two unappealing choices:

> (1) Go forward with rules we *know* are wrong, assuming implementers
> will clean up the mess (with the complete loss of portability that
> entails)

No I don't see the problem as nearly so intractable, and in fact I think the
details that we are discussing now are pretty unimportant details. It is a
common phenomenon that language lawyers regard problems of no great importance
as significant :-)

> (2) Abandon Ada 2012 altogether, restarting it whenever we figure this
> stuff out to true agreement (essentially making it Ada 2014).

To me this is a strawman of no significance at this stage. If ISO delays the
standard it would not have much effect on the implementation scene, which is
what matters to users *other* than language lawyers. But the effect which it
*would* have would be wholly negative, and it would be unfortunate to delay over
essentially unimportant minor points.

Just to be clear, to me as a user, looking at all the suggestions that have been
made for predicates, I see no big significant difference between them, these are
VERY minor semantic points if you ask me.

Yes, I know they seem big, language design discussions always have that effect!

****************************************************************

From: Tucker Taft
Sent: Monday, March 5, 2012  6:53 PM

I think a rule that associates the assertion policy with the location of the
"final" explicit predicate expression that is applicable to the subtype could
work.  The only other alternative that seems to be simple enough to be
understandable at this point is the suppress model, where it is erroneous if you
suppress it and it would have evaluated to False.

I would recommend a straw vote at this point to see which way most folks are
leaning:

1) Assertion_Policy applies to subtype predicates, based on the last explicit
   predicate aspect clause, and the effect is that the predicates are not
   checked on conversion, etc., but are still relevant for membership tests,
   full case-statement coverage, etc.

   or

2) Suppress(Predicate_Check) applies to predicates, and it is erroneous if the
   check would have returned False at the point of a suppressed check.

Personally, I am on the fence between these two.

****************************************************************

From: Robert Dewar
Sent: Monday, March 5, 2012  7:15 PM

I strongly favor 2). I have given my reasons. I think that whatever you say in
the RM, ordinary programmers will think of predicates as being like constraints.
It won't matter very much if you choose 1) and their thinking is not quite
accurate, since as I said earlier, in the case where the predicate is not
violated, the two rules are equivalent, and I think most programmers will figure
if they suppress predicate checking they had better make sure the predicates are
not violated.

But all in all, given that programmers will inevitably think of predicates as
being like constraints, they may as well behave as much like constraints as
possible.

****************************************************************

From: Steve Baird
Sent: Monday, March 5, 2012  7:49 PM

> ...
> it is erroneous if the check would have returned False at the point of
> a suppressed check.

With suppressed checks, Ada05 gives us an unambiguous definition of when a
program crosses the line into erroneousness.

The line doesn't seem so clearly defined when we allow arbitrary boolean
expressions.

Consider, for example, a predicate which has side effects.

I know that such predicates are considered to be poorly behaved, but I still
want the language to be well-defined if someone does choose to write such a
thing.

What is the state of a program which depends on the value of a global variable
that a predicate function "would have" updated?

Is an implementation allowed (but of course not required) to perform a
suppressed assertion check?

Maybe there are no serious problems here - I haven't had a chance to think
things through - but I feel nervous about this.

Can we go with 90% of the suppression model, but keep the rule that a suppressed
predicate check is simply not performed (or perhaps it is
implementation-dependent as to whether the check is performed, but there are
only two options: it is, or it isn't).  I generally like the suppression model,
but I'd feel better if we could avoid using "would have in some alternative
universe" stuff to define erroneous execution.

****************************************************************

From: Bob Duff
Sent: Monday, March 5, 2012  7:51 PM

> Well they may be more like assertions from a detailed legalistic
> semantic point of view, but the fact remains that they are like
> constraints from the programmers point of view

Well, I agree, but in fact all of the following are pretty-much alike from the
programmer's point of view:

    constraints (range, index, discrim)
    null exclusions ("not null")
    predicates
    invariants
    preconditions
    postconditions
    pragma Assert
    if ... then raise Blah
    when others => raise Program_Error;

Only the details are different.

Did I forget any?  I'd mention digits_constraint and delta_constraint, except
most programmers have probably never heard of those.

> No I don't see the problem as nearly so intractable, and in fact I
> think the details that we are discussing now are pretty unimportant
> details.

Exactly.

>...It is a common phenomenon that language lawyers regard problems  of
>no great importance as significant :-)

Right, sometimes it's hard for language lawyers to take off the "lawyer" hat and
put on the "plain old programmer" hat.  ;-)

****************************************************************

From: Bob Duff
Sent: Monday, March 5, 2012  8:00 PM

> Since assertions (general name) are the most important thing about Ada
> 2012, it appears that we have two unappealing choices:
> (1) Go forward with rules we *know* are wrong, assuming implementers
> will clean up the mess

That would be just fine.  I find it only mildly "unappealing".

>... (with the complete loss of portability that entails); or

There's no loss of portability when checks are turned ON.

And in the big scheme of things, it really doesn't matter that much if there's a
loss of portability when checks are turned OFF.

> (2) Abandon Ada 2012 altogether, restarting it whenever we figure this
> stuff out to true agreement (essentially making it Ada 2014).

I never understood the hurry for 2012, but now that it's almost done, it would
be pretty silly to delay just because the rules for turning off checks are
somewhat bogus.

Look at the big picture!

****************************************************************

From: Tucker Taft
Sent: Monday, March 5, 2012  8:04 PM

> Can we go with 90% of the suppression model, but keep the rule that a
> suppressed predicate check is simply not performed (or perhaps it is
> implementation-dependent as to whether the check is performed, but
> there are only two options: it is, or it isn't). I generally like the
> suppression model, but I'd feel better if we could avoid using "would
> have in some alternative universe" stuff to define erroneous
> execution.

I don't think that really works, unless you go for something based on the
location of a use in some declaration, and I think we agreed that was getting
pretty complicated.

On the other hand, we could perhaps distinguish static and dynamic predicates,
and say that the compiler can never assume a dynamic predicate evaluates to
true, since we know dynamic predicates are not always well behaved.  On the
other hand, a static predicate is pretty well defined, definitely doesn't have
any side effects, and is about as equivalent to a range constraint as you can
get, so it is well defined to say what it means to assume it is true even
without checking it.

****************************************************************

From: Robert Dewar
Sent: Monday, March 5, 2012  8:04 PM

> I know that such predicates are considered to be poorly behaved, but I
> still want the language to be well-defined if someone does choose to
> write such a thing.

I don't care, why not say it is a bounded error to have side effects, and the
possible effects of a suppressed check is that it might or might not update the
global or may set it to some unexpected value.

> What is the state of a program which depends on the value of a global
> variable that a predicate function "would have"
> updated?
>
> Is an implementation allowed (but of course not required) to perform a
> suppressed assertion check?

I don't care one way or another

> Can we go with 90% of the suppression model, but keep the rule that a
> suppressed predicate check is simply not performed (or perhaps it is
> implementation-dependent as to whether the check is performed, but
> there are only two options: it is, or it isn't).  I generally like the
> suppression model, but I'd feel better if we could avoid using "would
> have in some alternative universe" stuff to define erroneous
> execution.

I think it is fine to insist on the predicate check not being performed if it is
suppressed. After all the only reason we don't insist on the check being
suppressed in the constraint case is that it may be infeasible or too expensive
to suppress the check (e.g. if it is free in hardware), and that reasoning does
not apply to predicates.

****************************************************************

From: Robert Dewar
Sent: Monday, March 5, 2012  8:09 PM

> On the other hand, we could perhaps distinguish static and dynamic
> predicates, and say that the compiler can never assume a dynamic
> predicate evaluates to true, since we know dynamic predicates are not
> always well behaved.  On the other hand, a static predicate is pretty
> well defined, definitely doesn't have any side effects, and is about
> as equivalent to a range constraint as you can get, so it is well
> defined to say what it means to assume it is true even without
> checking it.

I could live with that certainly

****************************************************************

From: Randy Brukardt
Sent: Monday, March 5, 2012  9:47 PM

...
> Can we go with 90% of the suppression model, but keep the rule that a
> suppressed predicate check is simply not performed (or perhaps it is
> implementation-dependent as to whether the check is performed, but
> there are only two
> options: it is, or it isn't).  I generally like the suppression model,
> but I'd feel better if we could avoid using "would have in some
> alternative universe" stuff to define erroneous execution.

I don't think that works, because it would mean that both (1) you have no
control over whether clients make a check or not and (2) the program is not
erroneous if the check fails. Which means that any predicates could not affect
correctness in a body.

To take a concrete example:

The vector container has the following routine:

function Element (Position  : Cursor) return Element_Type;
   -- If Position equals No_Element, then Constraint_Error is propagated.
   -- Otherwise, Element returns the element designated by Position.

Ignoring for the moment the exact exception being raised, this could (and
probably should) be written as:

     subtype Element_Cursor is Cursor
         with Dynamic_Predicate => Has_Element (Element_Cursor);

I'm using a predicate here because there are quite a few routines with such a
requirement, and repeating it over and over in preconditions is not appealing.
[I'm not thrilled by the subtype name here; Ada.Containers does not have a
concept of a "null" cursor by that name, and "valid" means something else. I
don't want to spend too long on this example, so I used the first name that
works.]

    function Element (Position : Element_Cursor) return Element_Type;
        -- Element returns the element designated by Position.

A precondition would work, of course:

    function Element (Position : Cursor) return Element_Type
        with Pre => Has_Element (Position);
        -- Element returns the element designated by Position.

In both cases, this is assuming that Assertion_Policy is Check, and this is
specified inside the package Ada.Containers.Vectors.

Now, the problem is that if the client Suppresses predicate checks, then the
predicate check is not made at the call site. If the resulting body is *not*
erroneous, then the only possibility for a correct implementation of the
original specification is to repeat the check within the body of Element.

OTOH, an Assertion_Policy of Ignore at the client site would have no effect on
whether the Precondition is checked, so it in fact could be used in this way.

The net effect is that Dynamic_Predicates could not be used to define checking
for parameters [without repeating the checks in the body]. And that is 90% of
the uses I envison for them (these are very similar to null exclusions in that
way, 90% of uses being associated with parameters).

At least if the effect is erroneousness, we don't have to care whether the body
works or not. And as Robert says, most users will understand that. (I'd prefer
to avoid erroneousness; indeed, I tend to recheck parameters that may be called
from client code where we don't control the checking specifically to avoid
erroneous execution, but I realize I'm unusual here.)

Note that if we *don't* use the predicate, and just check the rules in the body,
we don't have any possible erroneousness nor incorrectness. Nor do tools get a
chance to do verification or remove the extra error path from the code.

****************************************************************

From: Randy Brukardt
Sent: Monday, March 5, 2012  9:52 PM

...
> I would recommend a straw vote at this point to see which way most
> folks are leaning:
>
> 1) Assertion_Policy applies to subtype predicates, based on the last
> explicit predicate aspect clause, and the effect is that the
> predicates are not checked on conversion, etc., but are still relevant
> for membership tests, full case-statement coverage, etc.
>
>    or
>
> 2) Suppress(Predicate_Check) applies to predicates, and it is
> erroneous if the check would have returned False at the point of a
> suppressed check.
>
> Personally, I am on the fence between these two.

I prefer (1), for the reasons outlined in my previous messages: (1) I'd rather
not add more erroneous execution to the language, and without it, predicates
can't be used to check "semantics"; and (2) I don't want to rewrite all of the
11.4.1 stuff to exclude predicates from "assertions" but then apply all of the
side-effect and protected operation rules to them. [Note that static predicates
really don't have issue (2), but it would be even messier to separate static and
dynamic predicates here.]

****************************************************************

From: Randy Brukardt
Sent: Monday, March 5, 2012  10:06 PM

...
> > Since assertions (general name) are the most important thing about
> > Ada 2012, it appears that we have two unappealing choices:
>
> > (1) Go forward with rules we *know* are wrong, assuming implementers
> > will clean up the mess (with the complete loss of portability that
> > entails)
>
> No I don't see the problem as nearly so intractable, and in fact I
> think the details that we are discussing now are pretty unimportant
> details. It is a common phenomenon that language lawyers regard
> problems of no great importance as significant :-)

You might be right in terms of the language design. But these are very important
details - get them wrong, and I (and many other programmers) will not be able to
use Dynamic_Predicates for a substantial fraction of their intended purpose.
That's very bad.

Moreover, even if we agree we want Suppression rules, I don't know how to
(re)word the rules in 11.4.1 that assume that predicates are "assertions". We
had so much trouble getting them right as it is (and that's assuming that
they're right now, probably a dubious assumption), redoing them is a very scary
task.

And the Standard is promised for delivery ASAP after March 1st (which has
already passed). Most likely, that will be sometime next week. This wording all
has to be done and letter balloted by then. That has me *very* scared.

****************************************************************

From: John Barnes
Sent: Tuesday, March 6, 2012  2:07 AM

I fear that I have not been following this properly (very busy on lectures on
the fourth dimension), but

...
>> I agree that the more we talk about them, the more
>> they resemble subtype constraints, and trying to give
>> them the same "pampering" we give the other assertion-like
>> things doesn't seem to be working.
>

Yes, yes, I felt that when writing that bit of the rat (which will now need
revising heavily). And do I get Value'First amd Value'Last as well?

****************************************************************

From: Bob Duff
Sent: Tuesday, March 6, 2012  5:14 AM

> I fear that I have not been following this properly (very busy on
> lectures on the fourth dimension), but

!!

> Yes, yes, I felt that when writing that bit of the rat (which will now
> need revising heavily). And do I get Value'First amd Value'Last as well?

If there's no predicate, you get 'First.  If Value is static, you get
Value'First_Valid.  Otherwise (there's a dynamic predicates), you get neither.

****************************************************************

From: Robert Dewar
Sent: Tuesday, March 6, 2012  7:21 AM

> If there's no predicate, you get 'First.  If Value is static, you get
> Value'First_Valid.  Otherwise (there's a dynamic predicates), you get
> neither.

Note that Value'First_Valid can also be used if there is no predicate, providing
there is at least one value (not a null subtype!)

****************************************************************

From: Bob Duff
Sent: Tuesday, March 6, 2012  6:00 AM

> You might be right in terms of the language design. But these are very
> important details - get them wrong, and I (and many other programmers)
> will not be able to use Dynamic_Predicates for a substantial fraction
> of their intended purpose. That's very bad.

Randy, this is is just over-the-top pessimistic!

I'm quite sure we WILL get these rules wrong.  So what?
We'll work it out over the next couple of years.
Implementers will do what their customers need, and ARG will adjust the rules
accordingly.

> Moreover, even if we agree we want Suppression rules, I don't know how
> to (re)word the rules in 11.4.1 that assume that predicates are "assertions".
> We had so much trouble getting them right as it is (and that's
> assuming that they're right now, probably a dubious assumption),
> redoing them is a very scary task.

Don't panic.  Steve is going to produce some wording.
If he gets it wrong, the sky will not fall.

Compiler writers are going to understand one way or another, whether predicates
go by "erroneous" rules or "ignore" rules. It really doesn't matter whether or
not the wording says they are "assertions".

> And the Standard is promised for delivery ASAP after March 1st (which
> has already passed). Most likely, that will be sometime next week.
> This wording all has to be done and letter balloted by then. That has me
> *very* scared.

Take some advice from Alfred E. Newman.  ;-)

****************************************************************

From: Robert Dewar
Sent: Tuesday, March 6, 2012  7:24 AM

> I don't think that works, because it would mean that both (1) you have
> no control over whether clients make a check or not

I really think it is a waste of time to worry about this. If people turn off
checks, they get what they get, I think that worrying too much about the status
of programs with checks that are turned off and fail is pointless.

I copy Yannick on this, because he is in charge of a major project
(Hi-Lite) that is concerned with mixing tests and proofs, and I think his
perspective may be useful. Yannick, can you review this thread?

****************************************************************

From: Robert Dewar
Sent: Tuesday, March 6, 2012  7:30 AM

> You might be right in terms of the language design. But these are very
> important details - get them wrong, and I (and many other programmers)
> will not be able to use Dynamic_Predicates for a substantial fraction
> of their intended purpose. That's very bad.

You keep saying this, but frankly I don't see "many other programmers"
here, and I don't sympathize with your concerns, since I think they are
misplaced. You are trying to push the language into a "Randy Brukardt" mold here
when it just doesn't fit, and doesn't fit with normal Ada usage.

> Moreover, even if we agree we want Suppression rules, I don't know how
> to (re)word the rules in 11.4.1 that assume that predicates are "assertions".
> We had so much trouble getting them right as it is (and that's
> assuming that they're right now, probably a dubious assumption),
> redoing them is a very scary task.

It's such a minor point to me, that I dont really care if the RM gets it 100%
right.

> And the Standard is promised for delivery ASAP after March 1st (which
> has already passed). Most likely, that will be sometime next week.
> This wording all has to be done and letter balloted by then. That has me *very* scared.

We can fix this with a binding interpretation if necessary. The Ada 2012 RM is
full of errors, I am sure of that, no reason to think we have succeeded in
producing an error free document where we never succeeded in doing this before.

Just as there is nothing special about a day when you don't know any of the
remaining bugs in a piece of software, and in practice you release software with
known bugs, there is nothing special about a problem we know about in the RM
when we release the RM compared to the myriad problems in the RM that we don't
know about.

So stop being scared, it is based on this faulty perception that there is some
merit in passing the Ada 2012 RM on to the next stage on a day when we are not
aware of any errors!

****************************************************************

From: Brad Moore
Sent: Tuesday, March 6, 2012  8:16 AM

1) They are like contraints
or
2) They are like invariants,
       (or like preconditions/postconditions that are implicitly applied
        on all calls involving the subtype)

The initial problem was that our Ada 2005 assertion policy was too course. We
decided we needed more fine-grained control, which led to our current (almost)
proposal. We are still saying that we would ideally like to have the ability to
ensure that checks are enforced in certain situations. That tells me that our
current proposal isn't fine-grained enough.

I haven't completely thought this through, but...

What if we added another assertion policy identifier, in addition to Check and
Ignore, call it Force, say.

The idea here is that such an assertion policy cannot be overridden, and it
requires the checks to be performed (like Check).

You could think of this as setting a Checks_Forced aspect on all subtypes
covered by the scope of the assertion policy pragma.

Hopefully that would satisfy Randy, and others who share his concerns,
(including myself), although like Tucker, I'm still on the fence with regard to
the straw poll. If I had to say which way I am leaning, I will say, option 1.

****************************************************************

From: Jeff Cousins
Sent: Tuesday, March 6, 2012  8:34 AM

Could this Force assertion policy also be used to force the checking of
constraints on subtypes, or, if we're keeping the model of different but
parallel systems of control for constraints and assertions, invent an
Unsuppressable aspect to force the checking of constraints on subtypes?

****************************************************************

From: Robert Dewar
Sent: Tuesday, March 6, 2012  8:38 AM

> What if we added another assertion policy identifier, in addition to
> Check and Ignore, call it Force, say.

I would not rush to add this to the RM. If such an assertion policy identifier
is useful, then implementations can add it.

****************************************************************

Questions? Ask the ACAA Technical Agent