Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

["Dan'l Miller" <optikos@verizon.net>]

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:
> > > <patrick@spellingbeewinnars.org> wrote:
> > > 
> > > > However I am discouraged with what you are saying about the bugs being on
> > > > the compiler side and not so much in the RTS.
> > > 
> > > It’s more the bugs are in the Ada front end, not the GCC backend, which is
> > > the codegen.
> > 
> > Although it might be quibbling over the definition of “front-end” and “back-end”, it is my belief that
> > the vast majority of the bugs outside of the runtime is either:
> 
> There is no quibbling, I was pointing out his error in what he thought was what.

No, I was the one at the risk of quibbling by pointing out that GNAT has this 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 trees, where the Ada semantic tree is in the Ada-language-source-code front-end 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 Ada _LRM_) most bugs are not in the GNAT true-•front•-end in Ada-language source-code nor in the GNAT true-•back•-end in C-language source-code shared with the rest of GCC.  I suspect that the vast majority of lingering compiler bugs in GNAT have their root cause in less-than-perfect tree-transduction from Ada semantic tree to C/C++-GENERIC/GIMPLE 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.
> > 
> > Luke, GIGI is the general vicinity for fulfilling your prophetic prediction 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/GIMPLE C/C++ semantic tree
> > (in C-language 
> 
> What are you going on about?

My sentences are precisely worded to say what needs to be said without further 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 eliminate GIGI.  Luke & Shark8 take
> > especial note:  eliminate the need for GIGI entirely, then one has a drastically entirely-different-than
> > GNAT design for a next-gen 
> 
> That's exactly the point, it would be a completely different design, a completely 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 “radical new design” of a next-gen Ada compiler.  We agree there.

> > Ada compiler.  Luke, despite your ridicule of studying Ada's antiquity, •that• elimination of GIGI is
> > precisely why studying William Wulf's DIANA from decades ago is intellectually stimulating &
> > rewarding as getting the creative juices flowing in the mind when contemplating what a next-gen Ada
> > compiler might have 
> 
> I never said anything about not learning from DIANA, I said don't implement 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 semantic information as a directed acyclic graph (DAG) is borrowable though in general 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 traversals of the AST to semantically adorning it during parsing more & more syntax that reveals more & more semantic-meaning and then finally to tree-transduce it to GENERIC/GIMPLE to synthesize the ‘equivalent’ C/C++-semantics tree.  The measure of GNAT's complexity (as an admirably clever engineering-design-trick achievement) is how many repeated transversals of a tree does it take to emulate a DIANA-esque semantic DAG's joins/unbranching.  At least some of the re-traversals of the true-front-end's Ada semantic tree seem to correspond to where one would expect joins/unbranching in a DAG.  More study in this vicinity will reveal more GIGI-specific wisdom and more DIANA-specific wisdom, and a useful conceptual isomorphism between 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: 
> > AdaAST-GIGI-C/C++AST, 2 separate trees and a transducer-of-clever-snippets between them.
> > (I suspect sometimes the scope of that cleverness there in GIGI is insufficiently
> > narrow/not-omniscient-enough, hence mistranscription bug.)
> 
> What the hell are you on about????

Unlike all other replies along all branches of all threads deriving from the OP, I actually started doing what the OP sought technologically:  start discussing the actual internal design of GNAT for the purpose of how to understand it for the purpose of how to maintain it.  (I am not sure that we need a new group/forum; what is wrong with discussing the design/internals of GNAT here on c.l.a?)