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=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a02:9862:: with SMTP id x31-v6mr4873536jaj.40.1535337511093; Sun, 26 Aug 2018 19:38:31 -0700 (PDT) X-Received: by 2002:aca:de07:: with SMTP id v7-v6mr231995oig.5.1535337510985; Sun, 26 Aug 2018 19:38:30 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!w19-v6no3058934itb.0!news-out.google.com!c63-v6ni3319ith.0!nntp.google.com!w19-v6no3058933itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 26 Aug 2018 19:38:30 -0700 (PDT) In-Reply-To: <1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <309225242.556906218.575482.laguest-archeia.com@nntp.aioe.org> <2145221813.556924687.162377.laguest-archeia.com@nntp.aioe.org> <3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com> <1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? From: "Dan'l Miller" Injection-Date: Mon, 27 Aug 2018 02:38:31 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 7722 X-Received-Body-CRC: 3416743019 Xref: reader02.eternal-september.org comp.lang.ada:54264 Date: 2018-08-26T19:38:30-07:00 List-Id: On Sunday, August 26, 2018 at 5:52:54 PM UTC-5, Lucretia wrote: > On Sunday, 26 August 2018 20:54:11 UTC+1, Dan'l Miller wrote: > > On Saturday, August 25, 2018 at 4:48:07 PM UTC-5, Luke A. Guest wrote: > > > wrote: > > >=20 > > > > However I am discouraged with what you are saying about the bugs be= ing on > > > > the compiler side and not so much in the RTS. > > >=20 > > > It=E2=80=99s more the bugs are in the Ada front end, not the GCC back= end, which is > > > the codegen. > >=20 > > Although it might be quibbling over the definition of =E2=80=9Cfront-en= d=E2=80=9D and =E2=80=9Cback-end=E2=80=9D, it is my belief that > > the vast majority of the bugs outside of the runtime is either: >=20 > There is no quibbling, I was pointing out his error in what he thought wa= s what. No, I was the one at the risk of quibbling by pointing out that GNAT has th= is weird not-truly-front-end, not-truly-back-end 3rd layer called GIGI tree= transducer to convert between the two (i.e., Ada versus C/C++) semantic tr= ees, where the Ada semantic tree is in the Ada-language-source-code front-e= nd and the C/C++ semantic tree is in the C-language-source-code back-end of= GNAT. My main point is: I suspect that (except for brand new revisions of the Ad= a _LRM_) most bugs are not in the GNAT true-=E2=80=A2front=E2=80=A2-end in = Ada-language source-code nor in the GNAT true-=E2=80=A2back=E2=80=A2-end in= C-language source-code shared with the rest of GCC. I suspect that the va= st majority of lingering compiler bugs in GNAT have their root cause in les= s-than-perfect tree-transduction from Ada semantic tree to C/C++-GENERIC/GI= MPLE semantic tree, due in turn to having blinders on or tunnel vision, not= looking at enough context in the large. > > On Saturday, August 25, 2018 at 5:05:52 PM UTC-5, Luke A. Guest wrote: > > > A new compiler needs a radical new design. > >=20 > > Luke, GIGI is the general vicinity for fulfilling your prophetic predic= tion of the future: A radical new > > Ada-compiler design would eliminate the tree-transducer's transcription= of snippets of Ada's > > semantically-adorned AST (in Ada-language source code) into GENERIC/GIM= PLE C/C++ semantic tree > > (in C-language=20 >=20 > What are you going on about? My sentences are precisely worded to say what needs to be said without furt= her rebuttal by me, stating the same thing again. If something specific is= unclear, please narrow your request for information. > > source code). In short, a radical new Ada-compiler design would elimin= ate GIGI. Luke & Shark8 take > > especial note: eliminate the need for GIGI entirely, then one has a dr= astically entirely-different-than > > GNAT design for a next-gen=20 >=20 > That's exactly the point, it would be a completely different design, a co= mpletely different compiler, > hence nothing from GCC/GNAT. Yes, eliminating GNAT's need for a tree transducer between 2 semantic trees= (one for Ada, the other for C/C++) is the =E2=80=9Cradical new design=E2= =80=9D of a next-gen Ada compiler. We agree there. > > Ada compiler. Luke, despite your ridicule of studying Ada's antiquity,= =E2=80=A2that=E2=80=A2 elimination of GIGI is > > precisely why studying William Wulf's DIANA from decades ago is intelle= ctually stimulating & > > rewarding as getting the creative juices flowing in the mind when conte= mplating what a next-gen Ada > > compiler might have=20 >=20 > I never said anything about not learning from DIANA, I said don't impleme= nt it. I seem to recall an unrelenting general pox on all historical-Ada houses as= the overall gist from you. > Reason is simple, it was designed using Ada83, we have OO now and OO fits= a compiler perfectly and > would be a hell of a lot nicer than a bunch of variant records/enums. Yes, we're narrowly in agreement there. DIANA's representing of the semant= ic information as a directed acyclic graph (DAG) is borrowable though in ge= neral for an OO redesign of DIANA. Conversely, GNAT's trick is to use the AST as a tree, not a true DAG, then = emulate the DAGness via the tree by repeated repeated repeated repeated tra= versals of the AST to semantically adorning it during parsing more & more s= yntax that reveals more & more semantic-meaning and then finally to tree-tr= ansduce it to GENERIC/GIMPLE to synthesize the =E2=80=98equivalent=E2=80=99= C/C++-semantics tree. The measure of GNAT's complexity (as an admirably c= lever engineering-design-trick achievement) is how many repeated transversa= ls of a tree does it take to emulate a DIANA-esque semantic DAG's joins/unb= ranching. At least some of the re-traversals of the true-front-end's Ada s= emantic tree seem to correspond to where one would expect joins/unbranching= in a DAG. More study in this vicinity will reveal more GIGI-specific wisd= om and more DIANA-specific wisdom, and a useful conceptual isomorphism betw= een them, as the 2 schools of thought effectively critique each other. > > at its heart instead of the bug-prone complication that GNAT has at its= heart:=20 > > AdaAST-GIGI-C/C++AST, 2 separate trees and a transducer-of-clever-snipp= ets between them. > > (I suspect sometimes the scope of that cleverness there in GIGI is insu= fficiently > > narrow/not-omniscient-enough, hence mistranscription bug.) >=20 > What the hell are you on about???? Unlike all other replies along all branches of all threads deriving from th= e OP, I actually started doing what the OP sought technologically: start d= iscussing the actual internal design of GNAT for the purpose of how to unde= rstand it for the purpose of how to maintain it. (I am not sure that we ne= ed a new group/forum; what is wrong with discussing the design/internals of= GNAT here on c.l.a?)