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: a07f3367d7,8143b93889fe9472 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII X-Received: by 10.180.89.100 with SMTP id bn4mr41753wib.7.1359687417580; Thu, 31 Jan 2013 18:56:57 -0800 (PST) Path: i11ni32291wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.87.MISMATCH!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newspeer1.nac.net!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!news.snarked.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada standard and maximum line lengths Date: Mon, 28 Jan 2013 16:13:42 +0100 Organization: cbb software GmbH Message-ID: <17adf7sj1i15v$.1k1xz901015cq.dlg@40tude.net> References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <1mr198uopixbw$.c81fe8oczrwv.dlg@40tude.net> <7e0f4106-9a87-4602-9098-125e920d9d47@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Date: 2013-01-28T16:13:42+01:00 List-Id: On Mon, 28 Jan 2013 02:02:54 -0800 (PST), Maciej Sobczak wrote: > W dniu poniedzia�ek, 28 stycznia 2013 09:18:43 UTC+1 u�ytkownik Dmitry A. Kazakov napisa�: > >>> I was reading the Ada 2012 standard and found this, I was just wondering >>> why there is a maximum line length, it's not like we parse the language a >>> line at a time. >> >> It is. I always accumulate a whole line before parsing it. > > But it is an implementation detail of your particular parser. As much as the reverse would be. [I answered because the OP presumed that no parser does it this way. At least one (mine) does.] > There is nothing in the concept of parsing itself that would require it. Actually there is something. It is the backtracking/look-ahead, which determines how much of the source need to be cached by the parser. One stream element is usually not enough, at least not sufficient to generate reasonable error messages. Lines are most natural to determine the boundaries of backtracking/look-ahead. >>> Why not just accept it as a stream of tokens and if there >>> are line breaks, ignore? >> >> For multiple reasons. Specifically regarding Ada, the language has syntax >> elements bound by the line end, e.g. comments etc. > > There is no problem reading the stream until some token (newline) is > found. Especially if the whole purpose of reading is to ignore the input, > as is the case with comments. That would not ignore line breaks as the OP suggested. > I do not see anything that would prevent the implementation that accepts > potentially indefinite line lengths, while still putting arbitrary limits > on identifiers. + limits on the string literal length. Otherwise, yes, it would be possible to do, though useless. Because other tools depend on sane line lengths even more than the parser does e.g. editors, debuggers, documenting, addr2line after all. > I would not be surprised if the permission to limit is a leftover from the > ice age of line printers, without any real association with today's > systems. Rather the opposite. If lines are the ice arge then unget is Permian. [ A parser like mine ensures that each lexical element in the focus is cached. This allows to avoid secondary caches and related overhead. E.g. an identifier or string literal is not accumulated during parsing. Rather its starting and end positions are determined and passed further. It is all in-place until stored. ] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de