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,4fd338e56f592cfb X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 X-Received: by 10.66.145.35 with SMTP id sr3mr5971537pab.6.1367322903477; Tue, 30 Apr 2013 04:55:03 -0700 (PDT) Path: bp1ni1106pbd.1!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 30 Apr 2013 06:55:03 -0500 Date: Tue, 30 Apr 2013 07:55:02 -0400 From: "Peter C. Chapin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: LALR parser question References: <85sj2aydwi.fsf@stephe-leake.org> In-Reply-To: Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-MhTddla+xFEogtcwPnfsI+0prHivELGiT4UnacrMaWQF9argTCJsfRZkgHr0qf+dw2ga5y86ykLwonS!zS3JGlXxS68USkY0PV7L2m5aBr4yMY14pZonC8CjIhB1JVbAOJeGj/4sTY5beqw= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2681 X-Received-Bytes: 2822 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: 2013-04-30T07:55:02-04:00 List-Id: On 04/30/2013 12:11 AM, Yannick Duchêne (Hibou57) wrote: > The main issue with this argument, is that performance isn't a big issue > at this stage. What comes next — analyses, transformations, code > generation — is more important for the overall performance of a > compiler. Then anyway, being exact is far more important than being > fast, for a compiler, and in that matter, the two previous points values > a lot more (the points about clarity and precision). I've started toying around with building an Ada 2012 parser using the ANTLR v4 parser generator tool. I haven't gotten very far with this yet so it's too early to draw any conclusions but ANTLR is quite powerful so I'm hoping the process will be fairly enjoyable... educational at least :) ANTRL v3 generates LL(*) parsers. I understand ANTLR v4 uses a somewhat different algorithm and is quite liberal with what it will accept. I started by just typing in the grammar in the Ada reference manual and, aside from the left recursive loops, ANTRL v4 accepted it as is. (I'm not naive enough to believe that's good enough... so don't worry about that). The cool thing about ANTLR v4 is that it separates the actions from the grammar itself so one can use the same grammar to generate parsers in multiple languages. At least that's the idea. It remains to be seen how well it will actually work for Ada. Peter