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=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:62cf:: with SMTP id d198-v6mr14723584itc.6.1523256032582; Sun, 08 Apr 2018 23:40:32 -0700 (PDT) X-Received: by 2002:a9d:5220:: with SMTP id e32-v6mr2034023oth.3.1523256032409; Sun, 08 Apr 2018 23:40:32 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!peer03.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!k65-v6no1791417ita.0!news-out.google.com!15-v6ni1006itg.0!nntp.google.com!k65-v6no1791415ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 8 Apr 2018 23:40:32 -0700 (PDT) In-Reply-To: <8fca2fed-2721-48dc-95e5-5b98e7c1fa70@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=165.255.63.57; posting-account=47Ol7goAAADT5rnqlkuv1VWtLKLRxZbE NNTP-Posting-Host: 165.255.63.57 References: <1b44444f-c1b3-414e-84fb-8798961487c3@googlegroups.com> <62ee0aac-49da-4925-b9aa-a16695b3fc45@googlegroups.com> <9879872e-c18a-4667-afe5-41ce0f54559f@googlegroups.com> <80db2d05-744f-4201-ba1b-4436f8040491@googlegroups.com> <59f9ab6d-d6ba-45ff-a6f0-c5699983d9e8@googlegroups.com> <1a390e22-f49f-4028-8e58-ca4d0f51e4b6@googlegroups.com> <8fca2fed-2721-48dc-95e5-5b98e7c1fa70@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <040b399d-7a5a-4573-a576-3b859f709da1@googlegroups.com> Subject: Re: Interesting article on ARG work From: Jan de Kruyf Injection-Date: Mon, 09 Apr 2018 06:40:32 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5743 X-Received-Body-CRC: 370686020 Xref: reader02.eternal-september.org comp.lang.ada:51405 Date: 2018-04-08T23:40:32-07:00 List-Id: On Monday, 9 April 2018 05:50:32 UTC+2, Dan'l Miller wrote: > On Sunday, April 8, 2018 at 3:09:55 PM UTC-5, Dmitry A. Kazakov wrote: > > On 2018-04-08 21:48, Dan'l Miller wrote: > > > On Sunday, April 8, 2018 at 2:46:15 AM UTC-5, Dmitry A. Kazakov wrote= : > > >> if Foo then > > >> @ Bar; > > >> @ end if; > > >> @ if Boo then > > >> Baz; > > >> end if; > > >> > > >> would not be legal either. > > >=20 > > > Where =E2=90=A0 is the ASCII/ISO646 space character (presented as a g= raphical character for visualization herein), > > >=20 > > > if Foo then > > > =E2=90=A0 Bar; > > > =E2=90=A0 end if; > > > =E2=90=A0 if Boo then > > > Baz; > > > end if; > > >=20 > > > and > > >=20 > > > if Foo then > > > -- Bar; > > > -- end if; > > > -- if Boo then > > > Baz; > > > end if; > > >=20 > > > both are legal Ada statements, spurious and non sequitur evocations o= f the ARM notwithstanding. > > >=20 > > > In general, Dmitry, you seem to not understand that a generalized lef= t-right (GLR) parser would parse both sides of the @ concurrently. Your en= tire premise is that it is impossible to parse both presence and absence of= @ at the same time. In GLR, you are incorrect. > >=20 > > No, I don't understand what are you trying to say or how is it related= =20 > > to the issue discussed. >=20 > I am saying that your insistence on conformance of the extent of the @-co= de to any portion of the BNF (or anything else) in the ARM is 100% misguide= d, tantamount to being a troller fisherman. >=20 > I am saying that you are 100% incorrect that only the presence or only th= e absence of the @-code will be compiled in the most-exemplary implementati= on, leaving the other uncompiled variant to bit-rot uncompiled for extended= periods of time. I am saying that you sure appear to be quite ignorant of= GLR parsers' ability to parse both the presence and absence of the @-code = =E2=80=A2=E2=80=A2concurrently in the same invocation=E2=80=A2=E2=80=A2 of = the compiler in O(n) time in this case (because the @ mechanism does not su= ffer combinatorial explosion of, say, C preprocessor's arbitrarily-nested #= if...#endif constructs, which in their worst case can evoke GLR parsers' O(= n=C2=B3)-growth time on top of the combinatorial explosion's growth rate). = GLR parsers accomplish this by forking/bifurcating the push-down automata'= s reduced-production stack before rejoining the forks into traditional LR m= ode: one fork of the bifurcated reduced-production stack for =E2=80=A2pres= ence=E2=80=A2 of the @-code and one fork of the bifurcated reduced-producti= on stack for the =E2=80=A2absence=E2=80=A2 of the @-code. I am saying that= you apparently have not even read the Wikipedia article on GLR parsers: h= ttps://en.wikipedia.org/wiki/GLR_parser >=20 > I am saying that nearly everything that you have said among your multiple= replies to Randy's @-code is hogwash and horse-hooey. Perhaps. Every. W= ord. Of. It. (especially regarding your pontifications in the large for = all possible implementations that no well-oiled-machine spectacular impleme= ntation of the @-code is possible; perhaps you might hit the nail on the he= ad on a subpoint here and there regarding some less-than-exemplary implemen= tation). Dan'l please dont get over excited, we all live and learn you know. Even Dm= itry, and yes even I (though I hate to admit it!) You are probably quite right about what you see, from the place where you s= tand. But Dmitry stands in a different place and consequently sees differen= t things. Other than that I like to stress that most in the group know Dimtry's worth= to us. I would say he is quite valuable. Cheers, j.