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,8143b93889fe9472 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.98.103 with SMTP id eh7mr3014232wib.3.1359676492876; Thu, 31 Jan 2013 15:54:52 -0800 (PST) MIME-Version: 1.0 Path: i11ni32023wiw.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada standard and maximum line lengths Date: Thu, 31 Jan 2013 17:54:43 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <5107b329$0$6556$9b4e6d93@newsspool4.arcor-online.net> <5107eaed$0$6566$9b4e6d93@newsspool4.arcor-online.net> <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net> <51085776$0$6637$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1359676491 6934 69.95.181.76 (31 Jan 2013 23:54:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 31 Jan 2013 23:54:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-01-31T17:54:43-06:00 List-Id: "Robert A Duff" wrote in message news:wccwquucd1x.fsf@shell01.TheWorld.com... ... >>...but I still >> wouldn't like wasting significant amounts of memory (line/position >> information being stored in almost every symbol table entry) to carry >> almost >> no information. > > There are various ways to store line/column numbers compactly without > limiting line lengths. Really? Do tell! I know of no such technique that still would be usable (meaning does not involve indirection, which would add complication and fragmentation issues, and can be used at any time without calculation, because you don't know ahead of time when and where you'll need to generate error messages, debugging information, and traces). If you're not willing to waste space, you have to limit the size to 24-bits (maybe 32-bits at the outside); you might be able to use a couple of bits to control the divide between line numbers and positions, but really long line at the end of a really long file couldn't be handled (you'd run out of bits). For 24-bits, it's not worth it, and even using 32 you might as well just use a 10-bit position number and be done with it. If you only needed relative encoding, you could store the change from the last item in each time (limited to a small number of bits); that might work in the token stream [not the way we use it, but that's a different issue], but it wouldn't work in the symbol table or debugging information. Janus/Ada has line number and line position types declared in the Host package; these can be adjusted of course but we do the Ada thing and use strong typing so that someone doesn't use a line number as if it is a type handle. [Someone, ahem, has done that in the past.] So the storage options are limited. Randy.