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,FREEMAIL_FROM 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.224.190.193 with SMTP id dj1mr1775946qab.6.1359516164777; Tue, 29 Jan 2013 19:22:44 -0800 (PST) X-Received: by 10.49.98.42 with SMTP id ef10mr342932qeb.15.1359516164579; Tue, 29 Jan 2013 19:22:44 -0800 (PST) Path: k2ni3907qap.0!nntp.google.com!p13no6186500qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 29 Jan 2013 19:22:44 -0800 (PST) In-Reply-To: <15vb0qqqhjfhw.1oh0ihxfbhw5a.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=90.194.162.131; posting-account=L2-UcQkAAAAfd_BqbeNHs3XeM0jTXloS NNTP-Posting-Host: 90.194.162.131 References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com> <80a5c765-e5ff-4e7d-bc1b-e35f92a710a7@googlegroups.com> <15vb0qqqhjfhw.1oh0ihxfbhw5a.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8e359168-9f18-437c-8188-6d1bd85ebed6@googlegroups.com> Subject: Re: Ada standard and maximum line lengths From: Lucretia Cc: mailbox@dmitry-kazakov.de Injection-Date: Wed, 30 Jan 2013 03:22:44 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-01-29T19:22:44-08:00 List-Id: On Tuesday, 29 January 2013 21:22:56 UTC, Dmitry A. Kazakov wrote: > On Tue, 29 Jan 2013 10:46:36 -0800 (PST), Lucretia wrote: > > > I will be implementing a scanner for Ada 2012 and then a parser, > > You don't need a separate scanner. Ada (as well as any other language) can > be parsed in single pass, including reading the source. Well I never said separate passes, it will be a scanner controlled by the parser, which will be recursive descent, i.e. usual form of match(token) type scanning. > > I will read the entire file into a buffer and then scan the buffer. > > A better approach would be to have an abstract type representing the source > with multiple implementations of, e.g. backed by a stream, by a file, by a > text buffer etc. I will have multiple representations, but that will be mainly due to character types, i.e. utf-8, wide, etc. But if the tokens are not copied into the AST but a token is a record consisting of a start and end position within the buffer then it cannot be a file, the whole thing has to be read into memory at the start, i.e. before scanning. Luke.