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 X-Google-Thread: a07f3367d7,dbbbb21ed7f581b X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!195.14.215.230.MISMATCH!news.netcologne.de!newsfeed-hp2.netcologne.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Operation can be dispatching in only one type Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <025105f2-5571-400e-a66f-ef1c3dc9ef32@g27g2000yqn.googlegroups.com> <59acf311-3a4a-4eda-95a3-22272842305e@m16g2000yqc.googlegroups.com> <4b150869$0$6732$9b4e6d93@newsspool2.arcor-online.net> <18vlg095bomhd.8bp1o9yysctg$.dlg@40tude.net> <4b152ffe$0$7615$9b4e6d93@newsspool1.arcor-online.net> <19nhib6rmun1x$.13vgcbhlh0og9$.dlg@40tude.net> <4b1557d0$0$7623$9b4e6d93@newsspool1.arcor-online.net> <4b15bf2b$0$7623$9b4e6d93@newsspool1.arcor-online.net> <1jcbtmi5rztyp$.norvlhez9i9$.dlg@40tude.net> <4b179ffb$0$6591$9b4e6d93@newsspool3.arcor-online.net> <1gcigitaii0u0.1psu2vj52e66g$.dlg@40tude.net> Date: Tue, 8 Dec 2009 10:22:59 +0100 Message-ID: <1wv3of2u7rbx8.4a6yeffk4uf3.dlg@40tude.net> NNTP-Posting-Date: 08 Dec 2009 10:23:00 CET NNTP-Posting-Host: 9937b91b.newsspool4.arcor-online.net X-Trace: DXC=lofZ\nIjcA7T2Rfi67enW;^6ZC`4IXm65S@:3>?3lP_A On Mon, 7 Dec 2009 18:19:11 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1gcigitaii0u0.1psu2vj52e66g$.dlg@40tude.net... >> On Fri, 4 Dec 2009 20:45:19 -0600, Randy Brukardt wrote: >> >>> Writing in Ada 2012 as proposed today >>> (and that might change before it gets standardized): >>> >>> procedure Do_Something (Window : Claw.Basic_Window_Type; ...) >>> with Pre => Is_Valid (Window); >> >> Why not to allow such constraints for subtypes? E.g. >> >> subtype Valid_Window_Type is Window_Type when Is_Valid; >> >> then simply: >> >> procedure Do_Something (Window : Valid_Window_Type; ...) > > That's also under consideration, but there are some problems with it. One > problem is that such types are very confusing in array indexes/slices (do > the values all participate or just the ones that pass the predicate?) Only ones of the subtype, obviously. But the problem is same as with the index sliding: when two subsets of the index are equivalent, either nominally (when elements are same) or structurally (when the number of elements is same + maybe other conditions). Structural equivalence might appear convenient, but it is always a source of confusion. > are a couple of others as well. > > Another issue is that not all preconditions/postconditions can be written > this way. For one thing, a precondition can depend on multiple parameters at > once. Another issues is that the entry condition and exit conditions may be > different for a parameter. For instance, from Claw: > > procedure Create (Window : Basic_Window_Type; ...) > with Pre => not Is_Valid (Window), > Post => Is_Valid (Window); Mutating [sub]type? That looks like a case for a constructor to me (an old discussion). > So subtypes cannot completely replace pre and post conditions, but they can > be a complement to them. Absolutely. However I consider it differently. In my view pre-/postconditions and invariants should be static, used strictly for program correctness proofs. Subtypes should complement them for dynamic run-time checks (recoverable faults). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de