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!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: function Is_Open (File : File_Type) return Boolean; :Text_io Date: Tue, 27 Oct 2015 16:26:57 +0100 Organization: cbb software GmbH Message-ID: <135hiczk56x02.1xixcme8btbl4.dlg@40tude.net> References: <87twpd2qlo.fsf@theworld.com> <1pj15r7pul7f1.15qgdyrc8k133$.dlg@40tude.net> <87pp0030c1.fsf@theworld.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: TWQ9mg4k1m/sph/eQ+zHLA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:28077 Date: 2015-10-27T16:26:57+01:00 List-Id: On Tue, 27 Oct 2015 09:30:54 -0400, Bob Duff wrote: > "Dmitry A. Kazakov" writes: > >> On Mon, 26 Oct 2015 18:48:51 -0400, Bob Duff wrote: >> >>> comicfanzine@gmail.com writes: >>> >>>> Can someone please show my a code in which this function is used , i'm >>>> lost , thanks . >>> >>> Most code is written so that it is statically known whether a file is >>> open, so Is_Open is close to useless. Not entirely useless -- you might >>> use it in an assertion, such as: >>> >>> subtype Open_File is File with Predicate => Is_Open(Open_File); >> >> In order to have the Constraint_Error exception instead of Status_Error? > > No, in order to document the fact that a certain formal parameter must > be open, and in order to prove things statically. If a procedure takes > "F: Open_File", then we can easily prove that writes to F within that > procedure do not raise Status_Error. That does not make sense either. There is nothing in the procedure itself that would prevent raising Status_Error. Everything is on the caller's side. How do you know if some callers would not appreciate Status_Error as a possible outcome? Looks like poor design to me. Anyway proving either of the conditions A) not raising Constraint_Error, B) not raising Status_Error look equally hard. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de