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,b5cd7bf26d091c6f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Reading the while standard input into a String Date: Mon, 6 Jun 2011 22:10:49 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1e5e764d-eb7b-4804-8119-b535ddbe5e7e@32g2000vbe.googlegroups.com> <1a84tm53l1wjx.1xdgsbp25vyd5.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1307416251 30878 69.95.181.76 (7 Jun 2011 03:10:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 7 Jun 2011 03:10:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-RFC2646: Format=Flowed; Original Xref: g2news2.google.com comp.lang.ada:20635 Date: 2011-06-06T22:10:49-05:00 List-Id: "Maciej Sobczak" wrote in message news:a5b07c48-756b-41fd-bd85-c95016702a73@hv8g2000vbb.googlegroups.com... On Jun 6, 8:18 pm, "Dmitry A. Kazakov" wrote: >> > This is a can of warms - how big should be that chunk? :-) >> >> For a compiler it is the maximal length of look ahead / roll-back, >> normally, less than just one line. > >This is wrong even for Ada. The compiler cannot drop what it read so >far (except maybe for comments) - it has to retain this information, >even if not literally in its original form. This means that "dropping" >data is not possible and in fact the internal data structures will >grow while the file is being processed - but then the compiler might >as well just read the whole source file into memory and I bet this >will be much smaller that the data structures that are built from it. Dmitry is right. Janus/Ada uses a small text buffer for the incoming source (back in the CP/M days is was 128 bytes, which matched the I/O size of the OS - it's somewhat larger now). We don't check any source beyond that; the source is converted into tokens which are far smaller than the original source in most cases. (Tokens for numeric literals might be larger than the corresponding literal.) And we don't keep that in memory, either; the entire set of tokens is written into a parsing stream which drives other compiler passes. This is all heavily encoded and optimized (the design was necessary to get the compiler to run at all on the small CP/M and MS-DOS systems) -- limiting the compiler to compiling programs of less than 8K of source would never have been a realistic option. >BTW - what about generating debug version of the executable with >source embedded? Oops. You'd better keep it around, it's cheap when >compared to anything else. Line/position information is far smaller than the source code (and is even smaller than a pointer to the source code), and that's needed anyway to make decent error messages. (Janus/Ada limits the source lines in a file to 65000, line lengths to 250). ... >There is no point in following this advice, because compiler is not >cat or grep. In particular, the compiler does not work on potentially >infinite streams (unlike cat and grep) and there is a clear concept of >a program structure that has its end. This means that reading the >whole source file into memory is a perfectly valid approach. That wouldn't be a practical approach -- source files can be very large (especially when generated by a tool). I've worried about that limit of 65000 lines (not that I've personally seen a file that exceeded it), as I've seen tools that turn very large data structures into Ada code. Randy.