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,585fd78267abd80c X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: On pragma Precondition etc. 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: <4889886d$0$18827$9b4e6d93@newsspool2.arcor-online.net> <6etsi6F8mbmbU2@mid.individual.net> <488efc8d$1@news.post.ch> Date: Tue, 29 Jul 2008 14:08:50 +0200 Message-ID: NNTP-Posting-Date: 29 Jul 2008 14:08:50 CEST NNTP-Posting-Host: 5ebe20c1.newsspool3.arcor-online.net X-Trace: DXC=36\A4Nc5D\TV;Ef1`Jk54\McF=Q^Z^V3X4Fo<]lROoRQ4nDHegD_]RUnnAolk[G:]T[6LHn;2LCV^7enW;^6ZC`TIXm65S@:3>_KIGgK73Di:X X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1373 Date: 2008-07-29T14:08:50+02:00 List-Id: On Tue, 29 Jul 2008 13:18:37 +0200, Martin Krischik wrote: > It too think a dedicated syntax would be best. Agree. > However, I suggest to > take a good look at task and protected types for guidance. No. Barriers are invisible implementation details. Pre-/post-conditions describe the contract. > Protected types already have an precondition. I know they are attached > to the body and a protected type blocks until the condition becomes true. Barrier expression is not a precondition (nor a post-condition, nor an invariant). > But the idea behind is still similar and so should be the syntax. No, the syntax should be bound to the parameter types. Georg already mentioned the inheritance issue. It is a very (probably the most) important point, because contracts are subject to inheritance. The problem with this is that the conditions are traditionally considered in a more loose, untyped context. Their expressions involve all parameters. In fact it means that they are bound to the anonymous type of the type of subprogram parameters. This makes the issue of inheritance quite difficult, especially, because inheritance on tuples of types is basically equivalent multiple-dispatch. So... > And how about Invariants (http://en.wikipedia.org/wiki/Class_invariant)? Same problems. Syntax issues are inferior, IMO. But I agree, no more new keywords, please! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de