Re: Meaning of “contractual” according to Ada

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Wed, 06 Mar 2013 23:35:54 +0100, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:

> "Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
>
>> Because naming and wording matters, especially with Ada :-P , I have
>> this  question.
>>
>> http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html
>> Says:
>>> These are not really contractual in the sense thatpreconditions,
>>> postconditions and invariants arecontractual but are more akin to
>>> constraints.
>>
>> What's not contractual with subtype predicates? And so what does
>> “contractual” means exactly for Ada's definition authors?
>
> There's no Ada-specific meaning for "contractual".  You are quoting
> the Rationale, not the RM.  ;-)

Yes, I knew, I was just plain wrong referring to “Ada's definition  
authors” ;-)

> If you have a formal parameter of subtype T, then T's predicate
> forms part of the contract between the procedure body and its
> callers.  So does T's constraint.  So I'd say predicates and
> constraints are "contractual" in that sense.
That's how I understand it too.

> I think what John means is that predicates (like constraints)
> can be used in cases like "X := Y + 1;" where there's no
> clear boundary between abstractions, with a contract between
> those abstractions.  It's just checking that Y+1 obeys the
> constraints and predicates of X.

> John is right that predicates are like constraints.
Yes, and constraints are contracts… or not? Or may be constraints are just  
more general than contracts?

> We've got a bit of a mess:  5 or 6 kinds of constraint, "not null",
> predicates, and invariants, all of which are basically the same
> thing, with differences in minor details.  I'd prefer a language
> design that unified all those things.
Yes, unification of some other stuffs too would be nice :-P That's a job  
for Ada's successor in 3045.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University