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: a07f3367d7,8143b93889fe9472 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.88.200 with SMTP id bi8mr269862pab.13.1359496422891; Tue, 29 Jan 2013 13:53:42 -0800 (PST) X-Received: by 10.50.157.170 with SMTP id wn10mr483575igb.10.1359496422827; Tue, 29 Jan 2013 13:53:42 -0800 (PST) Path: 6ni24204pbd.1!nntp.google.com!f6no861560pbd.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 29 Jan 2013 13:53:42 -0800 (PST) In-Reply-To: <80a5c765-e5ff-4e7d-bc1b-e35f92a710a7@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <80a5c765-e5ff-4e7d-bc1b-e35f92a710a7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada standard and maximum line lengths From: Adam Beneschan Injection-Date: Tue, 29 Jan 2013 21:53:42 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-01-29T13:53:42-08:00 List-Id: On Tuesday, January 29, 2013 10:46:36 AM UTC-8, Lucretia wrote: > So, in short, I'm wondering whether it really matters to parse by breakin= g up into lines or not. If every source input that your program will get is a valid Ada program, th= en there's probably no need to "break up" the source into lines. But if th= ere are errors, then it can be useful for the program to at least be aware = of where lines begin and end--possibly for error reporting (so that you can= display a line number and maybe the whole input line), and if you want to = get really fancy, the program might be able to look at the indentation of a= line to make an educated guess about what the programmer intended, when th= ere's a missing "end" or something like that, which sometimes can help redu= ce the number of cascading error messages. It depends on what you want you= r program to do. But it's probably important to think about how your progr= am will handle errors in the input; and that's something that should be con= sidered right away in the design process, not as an afterthought. I don't know if this answers your question. Making sure the program is awa= re of where a line is isn't the same as "breaking up" into lines, but the t= erm "breaking up" isn't really well defined. However, if you're thinking a= bout writing a lexical scanning or parsing subroutine that takes one line o= f input as a parameter, I don't see any advantage in that. -- Adam