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,4cb1f8d1c17d39a8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.42.146.3 with SMTP id h3mr1824642icv.2.1320512186747; Sat, 05 Nov 2011 09:56:26 -0700 (PDT) Path: h5ni1594pba.0!nntp.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: Ada 'hello world' for Android; success! References: <8239efcjuw.fsf@stephe-leake.org> <98ca5430-aa52-4e39-b789-70d0dd6adb46@d33g2000prb.googlegroups.com> <824nyrq5p6.fsf@stephe-leake.org> <4eac1ca1$0$7625$9b4e6d93@newsspool1.arcor-online.net> <82mxciogt0.fsf@stephe-leake.org> <4eafbc25$0$6575$9b4e6d93@newsspool3.arcor-online.net> <82mxcemscg.fsf@stephe-leake.org> <4eb1e241$0$7627$9b4e6d93@newsspool1.arcor-online.net> <8239e5mo9q.fsf@stephe-leake.org> <4eb31240$0$6549$9b4e6d93@newsspool4.arcor-online.net> <82ty6kkrnc.fsf@stephe-leake.org> <4eb3fec1$0$6558$9b4e6d93@newsspool4.arcor-online.net> Date: Sat, 05 Nov 2011 12:56:23 -0400 Message-ID: <82ehxmjyo8.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) Cancel-Lock: sha1:Qqyn/jB0eXdVDPLWzu/hMdCKtXY= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 7c14e4eb56abae029e66108856 Xref: news2.google.com comp.lang.ada:14322 Content-Type: text/plain; charset=us-ascii Date: 2011-11-05T12:56:23-04:00 List-Id: Georg Bauhaus writes: > On 04.11.11 13:18, Stephen Leake wrote: > >> In current OpenToken, we have 'procedure Parse' instead of 'procedure >> Produce_Subprograms'; the rest is the same. I gather >> 'Produce_Subprograms' generates Ada code, that must then be compiled. > > Yes. > >> I'm not clear what the benefit of this is over the current OpenToken >> approach. > > Meant only to be a possible alternative, its implementation is trivial, > and it automatically reuses mechanisms such as a stack that > a traditional computer features as a built-in. :-) It occured to me that one reason to not use the current OpenToken is the need to run on Ravenscar, with a "no allocations" restriction. But I think I'd rather use bounded containers in that case; it should not be too hard to build a generic common interface. > The given method is exhaustive, if that's needed, it's there. > If there are no loops in the grammar itself (such as left recursion), > then the length of input determines the number of recursive > calls for this method, too, so use of stack space has a known > maximum. Ah; I hadn't thought of it that way. That makes this approach ok for Ravenscar. > From a programmer's perspective, the method shown will pass tokens > to handlers. Writers of SAX style content handlers will recognize > the scheme and find it familiar, I think. Yes. The equivalent "handlers" in OpenToken are just dispatching subprograms. > Following are some ideas that I would find fairly easy to add > to the resulting parsers, to make them more useful, more efficient, > or even more powerful. > Are they equally easy to add to, for example, bottom up parsers? I think these are all just moving towards LR parsing; might as well just go there! -- -- Stephe