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: 103376,ea5071f634c2ea8b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.28.135 with SMTP id b7mr10939357pbh.8.1322214485494; Fri, 25 Nov 2011 01:48:05 -0800 (PST) Path: lh20ni16000pbb.0!nntp.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!gegeweb.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Generic-Package Elaboration Question / Possible GNAT Bug. Date: Fri, 25 Nov 2011 10:47:42 +0100 Organization: cbb software GmbH Message-ID: <1u91r9gjh5ep7.5o1zfpumqbfu$.dlg@40tude.net> References: <7bf9bc32-850a-40c6-9ae2-5254fe220533@f29g2000yqa.googlegroups.com> <4295dc09-43de-4557-a095-fc108359f27f@y42g2000yqh.googlegroups.com> <3snehoqgs8ia$.1nobjem6g6hx6$.dlg@40tude.net> <128rdz2581345$.c4td19l7qp9z$.dlg@40tude.net> <16ipwvpdavifr$.17bxf7if7f6kh$.dlg@40tude.net> <4ecb78b1$0$6643$9b4e6d93@newsspool2.arcor-online.net> <1iofgbqznsviu$.phvidtvxlyj4$.dlg@40tude.net> <4ecbb96e$0$6581$9b4e6d93@newsspool3.arcor-online.net> <743e83a1-c442-444b-a25a-da706e9cd0f9@g7g2000vbd.googlegroups.com> <011f483a-e0d7-4475-89e6-506802e88b9b@i6g2000vbe.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news1.google.com comp.lang.ada:19150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2011-11-25T10:47:42+01:00 List-Id: On Thu, 24 Nov 2011 14:48:46 -0800 (PST), Shark8 wrote: > On Nov 24, 4:10�am, "Dmitry A. Kazakov" > wrote: >> On Wed, 23 Nov 2011 19:07:55 -0800 (PST), Shark8 wrote: >>> On Nov 22, 10:23�am, "Dmitry A. Kazakov" >>> wrote: >>>> I don't care about trade marks and definitions given by reference >>>> manuals... >> >>> Why not; definitions are essential to understanding each other. >>> If someone saying 'hammer' means 'shotgun' then what does "I need a >>> hammer." mean? >> >> That is the reason. TM and RM are inclined to name hammer shotgun. >> >> DbC (TM) considerably deviates from design by contract (common sense), > > Unfortunately "common sense" is not intuitively obvious to everyone; > furthermore, "common sense" is hampered by the fact that natural- > language tends to contain connotations not within the actual > definitions of the words. It is still better than arbitrary slogans and advertising TMs and some RMs tend to. If you want definitions, they should be from scientific sources, peer reviewed, commonly accepted, [not funded by large vendors we all have in mind...]. Then a definition must *define* some really existing phenomenon. It is pointless to discuss DbC (TM) because it is not something which really exists. >> as >> Georg has explained willingly or not. For example disregarding separation >> of interface and implementation is not how things are designed by contract. > > I actually fail to see exactly where the interface/implementation > separation is an issue in Ada 2012. Executable code in declarations is. Dynamic contracts are. > In other words, it seems to me to be the natural progression of Ada > 2005's Null Exclusion. > Procedure Delete( Param : Not Null Access Link_List_Node ) is > begin > [Deletion operation] -- Hey, we can get rid of checking for Param = > Null here! > end Delete; Passing null is not a contract violation. If the goal was to extend composition means in Ada, .e.g. an ability to compose new operation F as F = Epilogue o G o Prologue I am not against that because I proposed such stuff myself. Just do not call Prologue precondition, because it is not. BTW, precondition, postcondition etc were introduced by Dijkstra for correctness proofs. It is DbC (TM) which misuses established terms, not me. > By moving the null-exclusion logic "to the parameter" we can get rid > of all the cases where, previously, we had to handle Null. Only when provable, i.e. when the compiler and the program reader *know* that the check is superfluous in the body. Note that there is much more use in statically enforced Prologue and Epilogue. E.g. it would allow to solve the notorious problem of handling dimensioned values in Ada. It is also necessary to have broken Ada constructors and destructors working. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de