What is a Contract? (was: Suffix _T for types found good)

[Georg Bauhaus <see.reply.to@maps.futureapps.de>]

Ray Blaak wrote:

> A type is a contract specifying behaviour and storage.

In the context of Ada types, this use of the word "contract" is
potentially eroding the very notion of contract.  A type is not
specific enough to be the same as a proper full contract:


Behavior includes time.  Most types don't say anything about time.
Behavior includes order.  Most types don't say anything about order
of operations.  The client party can choose any order of primitive
operations they wish. They can expect the operations to have finished
whenever these are done.  No contractual specifics.

Contracts say, "Provided earlier behavior X... ",
"Provided property P of A ... ". Most Ada types do not and cannot
currently have a contractual part of this sort.  There are no
premises right now, other than subtype constraints (recursively).

The client party to a type-contract is typically *not* granted access
to any piece of storage.  Client parties only see the
public view of a type. You could say that privacy is part of the
contract. Sure. This is what I mean by eroding the notion of "contract".

(It is typically not necessary to set up a contract between two parties
when all that it specifies is,
 "Client will not tear castle's walls down."
That's understood.)

A contract for object of a type typically *exludes* aspects of
storage. (Other than saying, this operation requires O(2*n) words
of computer storage. Said in comments...)

A contract is specific about expectations. "This function returns
a String" is unspecific at the level of "contract".  The client's
expectation in the sense of contract is, "What kind of String will
I get back?"


I think it might be advantageous to let "contract" mean the
essentials that make contract *different* from plain old
Ada type.


-- 
Georg Bauhaus
Y A Time Drain  http://www.9toX.d