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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,68cd50941308f5a9 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 11 Dec 2006 16:48:49 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1165514423.562024.70510@j72g2000cwa.googlegroups.com> <4-adnQeuHcj3DubYnZ2dnUVZ_oOonZ2d@comcast.com> Subject: Re: End_Of_File but not really Date: Mon, 11 Dec 2006 16:49:46 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-4WSXUTSfWcfoYisfJylTBkysGjeG/yRzmubajAlXudaV4xWD91Ol48lA8WJNFGUoFY6l8DchsyL4YIN!nm/gataTtvXELVZ1A0MAsoRk6d4lVhyhIujCDY108yIpGy034d37Kk/61asaZ9RmfihvvIIdh6K4!ZkJdmqn+wSLusg== X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:7895 Date: 2006-12-11T16:49:46-06:00 List-Id: "Steve" wrote in message news:4-adnQeuHcj3DubYnZ2dnUVZ_oOonZ2d@comcast.com... > > "Randy Brukardt" wrote in message > news:oJednfF3KqVVLOXYnZ2dnUVZ_q-dnZ2d@megapath.net... > [snip] > > > > As I noted before, there is absoletely no chance that this behavior (or > > any > > behavior of Text_IO) would be changed, because there's no possible way for > > such a change to the compatible. If the program "knows" about the "lost" > > blank line, it might fail badly if the definition was to be changed. So it's > > 23 years too late to fix Text_IO. > > Actually... couldn't the "Form" option that is passed to Open include an > option that changes the end of file behavior? That wouldn't break old code, > but would make new code easier. I suppose, but it wouldn't help much, because there is no "Form" for Standard_Input (it's already open). So the behavior of that can't be changed -- but that's where the worst problem is. So it's not clear that a new "Form" would be very useful (remember that the default behavior would still have to be the "bad" behavior). It's also clear that the bad behavior is inevitable with the current model of terminators. So we'd need a new underlying model, which sounds like a mess. Besides, getting programmers comfortable with using exceptions is a good thing: I/O can fail in many ways other than reaching the end, it's hardly sensible to write any I/O without some handlers. So I'd be more inclined to make the End_of_File function Obsolescent - it's much like the Constrained attribute and specific Suppress (which are already Obsolescent): it seems like they should work, but they don't. Net result: it's probably not worth the headache. Randy.