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,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cbb87dd49168c396 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-01 13:10:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!msunews!not-for-mail From: "Chad R. Meiners" Newsgroups: comp.lang.ada Subject: Re: Get_Line Date: Fri, 1 Nov 2002 16:04:50 -0500 Organization: Michigan State University Message-ID: References: <3DBF3659.30709@acm.org> <4dRv9.46453$wm6.7691@nwrddc01.gnilink.net> <3DC0204E.4050203@acm.org> Reply-To: "Chad R. Meiners" NNTP-Posting-Host: arctic.cse.msu.edu X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:30295 Date: 2002-11-01T16:04:50-05:00 List-Id: "Robert A Duff" wrote in message news:wccy98d2plj.fsf@shell01.TheWorld.com... > Well, maybe your students didn't have trouble. Maybe that means you're > a good teacher. But I know I've seen *many* questions about > Text_IO.Get_Line and related stuff on c.l.a. over the years. > And this stuff *ought* to be simple -- I'm not surprised when > a beginner is confused about discriminated tasks or something, > but when folks are confused about how to read in a line of text, > I think that indicates something wrong with the language. I see. I think the problem is that (simple) problems rarely actually call for a programs to just get a line of text. Often people think they need to get a line of text and parse it, but they could just parse the line directly with Ada.Text_IO's generic data type facilities. I agree though that reading an arbitrarily size string takes some work in Ada, but I would expect this since Ada doesn't natively support resizable arrays. This doesn't mean we should sit back and be content with Ada.Text_IO when we could extend it to make reading in a line a little more friendly, but we should leave the side-effects out of the functions within Ada.Text_IO. Would you be happy with the following instead? type Line is private; procedure Get_Line (File : File_Type; Item : out Line); function To_String (Item : Line) return String; > Sorry, I didn't mean to defame your character. I was just making an > analogy between side-effects in character-stream-reading functions, > and allocators, where for the latter we happily use function-call-like > notation. Okay, I didn't think you meant to defame; I was just making sure of your intent. > OK, that convinces me that my analogy was poor. > > Still, the reason "Do_Something (Get_Line, Get_Line, Get_Line);" is > wrong is that Ada does not define evaluation order. The mere > *existence* of a Get_Line function should not cause people to write > that. My concern is that when students are learning a new language they sometimes adopt a favorite part of the language and then proceed to try to use that part whenever possible. A Get_Line function has that certain appeal to it that would make it a good candidate for such abuse especially if the student knows c++. > I actually think that Ada *should* define the evaluation order, > precisely because the above example can cause bugs. Alternatively, > the language should forbid such examples at compile time, rather > than just giving wrong answers. I realize that Ada has no mechanism for > having such compile-time checking, because the compiler doesn't know > which global variables a given function reads and writes. I would definitively like to see warnings generated when possible! ;-) -CRM