From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "G.B." <bauhaus@notmyhomepage.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada 2012 Constraints (WRT an Ada IR)
Date: Thu, 15 Dec 2016 20:50:46 +0100
Organization: A noiseless patient Spider
Message-ID: <o2us43$gik$1@dont-email.me>
References: <c06ee4e6-d616-4e01-ba2e-cb111a81f6f6@googlegroups.com>
 <o2b9rg$ejl$1@dont-email.me> <o2bb4o$1jpb$1@gioia.aioe.org>
 <o2c93i$rpp$2@dont-email.me> <o2du2t$1ghu$1@gioia.aioe.org>
 <o2jcpd$75p$1@dont-email.me> <o2jgom$18jg$1@gioia.aioe.org>
 <o2jkdm$bt$1@dont-email.me> <o2js2d$1qh4$1@gioia.aioe.org>
 <o2ke6d$gcs$1@dont-email.me> <o2ln13$et0$1@gioia.aioe.org>
 <o2mfpc$ttp$1@dont-email.me> <o2mncc$gjn$1@gioia.aioe.org>
 <o2mroh$dsk$1@dont-email.me> <o2n2o1$1515$1@gioia.aioe.org>
 <o2o73n$ci1$1@dont-email.me> <o2obed$qkk$1@gioia.aioe.org>
 <o2oj2u$i8h$1@dont-email.me> <o2olfi$1ca9$1@gioia.aioe.org>
 <o2p9bb$bcf$1@dont-email.me> <o2po6a$1hnq$1@gioia.aioe.org>
 <999c67b0-4478-4d2b-8108-32ac48fe6316@googlegroups.com>
 <o2r0lo$175u$1@gioia.aioe.org>
 <a960c6dd-80aa-4c9f-bf3b-47da529e0e01@googlegroups.com>
 <o2s8l1$1fef$1@gioia.aioe.org>
 <f1cebe17-25b1-4f75-9c1d-ff89d869aa87@googlegroups.com>
 <o2tl0b$1af0$1@gioia.aioe.org> <o2trb6$aso$1@dont-email.me>
 <o2u54i$73i$1@gioia.aioe.org>
Reply-To: nonlegitur@notmyhomepage.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 15 Dec 2016 19:49:23 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="490cafcd859c79fdccfdd42353032c86";
	logging-data="16980"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/g04gKT9leXADoZMtjMGyUoveYBGBZ/3w="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
In-Reply-To: <o2u54i$73i$1@gioia.aioe.org>
X-Mozilla-News-Host: news://news.arcor.de
Cancel-Lock: sha1:y0DAXAsjPfL9XO0rb6jql32lPQw=
Xref: news.eternal-september.org comp.lang.ada:32852
Date: 2016-12-15T20:50:46+01:00
List-Id: <comp.lang.ada>

On 15/12/2016 14:17, Dmitry A. Kazakov wrote:
> On 15/12/2016 11:31, G.B. wrote:
>> On 15/12/2016 09:41, Dmitry A. Kazakov wrote:
>>> In Ada type declarations must be there, so it is not a tool, but an
>>> integral part of the language. This is why "pre"-aspects is a
>>> non-starter even ignoring their semantic consistency issues. You can
>>> do things with or without them. Psychologically it won't work.
>>
>> Problem statement:
>> Devise a type that represents an ordered pair of linearly
>> ordered numbers, such that programmers can create objects that
>> have the two elements in proper order.
>
> It is a good illustration of what is wrong with ideas you promote. You are thinking in terms of implementations.

Am I?  ;-)

In any case, I wasn't thinking of arithmetic at all. Maybe graphs'
edges. But certainly I had the simple concept of an order pair in mind.

Trying to follow your advice, though, with Post for emphasis,
lets see how well the type works without Pre.

    type Immutable_Ordered_Pair (<>) is private;

    function Make (First, Second: POT) return Immutable_Ordered_Pair
    with
      --Pre => First <= Second,   -- (*)
      Post => Make'Result in Immutable_Ordered_Pair; -- or raise

    function First (Pair : Immutable_Ordered_Pair) return POT;
    function Second (Pair : Immutable_Ordered_Pair) return POT;

Type POT has "<=", its name suggesting a partially ordered set.
The full view of Immutable_Ordered_Pair carries a hidden

    Type_Invariant => First <= Second;

naming obvious components, and it is hidden in the private part
as requested.

Now what will (*) yield if uncommented, thus ignoring your advice?
First, this is what Make could do without a Pre aspect:

   - raise some X_E if "<=" can raise X_E;

   - handle X_E and reorder the parameters ("At your service!")
     and retry, noting the attempt and raise X_E if "<=" does it
     again, otherwise return a pair made form the parameters reversed;

   - an unnecessary check in case the programmer passes First and
     Second properly ordered, i.e. (First <= Second) = True.

Now give the programmer Pre as it follows from {Post, Type_Invariant},
and you are designing by contract:

   - Make assumes Pre is true, so it simply returns a new object,
     since its assumption, Pre, entails {Post, Type_Invariant}.

It is contract violation if the programmer has passed values
not in "<=", violating Pre, so Make will not create and object.

Simple, no secrets, consistent, and efficient.

As opposed to:
Not Simple, arcane, consistent, and inefficient.

The reversal of parameters in the body of the rather complex Make
(when Pre is undisclosed) could instead be made a service procedure
or constructing function. For variables:

    procedure Swapped_As_Necessary (X, Y : in out POT)
    with
      Pre => True,
      Post => (if X'Old <= Y'Old
               then X = X'Old and Y = Y'Old
               else X = Y'Old and Y = X'Old);

But whenever an algorithm already has Post => x < y, then there
is no need to use that service procedure. Just call Make (x, y),
it is safe WRT contracts. Rest assured that Make won't raise A_F
and instead will produce objects as desired, and quickly.