* Studying and Maintaining GNAT, Is There Any Interest in a New Group? @ 2018-08-25 12:27 patrick 2018-08-25 13:56 ` Dan'l Miller ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: patrick @ 2018-08-25 12:27 UTC (permalink / raw) Hi Everyone If I started a new group with the goal of discussing GNAT internals and maintaining GNAT it outside of Adacore, would anyone join? As a group, we might be able to get the GCC people to adopt patches and features. A single person might not have the clout. It could give the language new life if the current free, open source compiler most of us use today continues to move in a direction towards unpaid hobbyist use or commercial use with high fees. It would be a moderated group and we could kick people out for posting about Pascal or human evolution 10 times a day :) We could create another section in the group for general questions too, for those that feel that the signal to noise here is not good. Please let me know-Pat ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 12:27 Studying and Maintaining GNAT, Is There Any Interest in a New Group? patrick @ 2018-08-25 13:56 ` Dan'l Miller 2018-08-25 16:00 ` patrick 2018-08-25 16:16 ` Luke A. Guest 2018-08-25 16:43 ` Jeffrey R. Carter 2 siblings, 1 reply; 55+ messages in thread From: Dan'l Miller @ 2018-08-25 13:56 UTC (permalink / raw) Name/affiliation alone will not be enough to influence anyone. Your clout would come from maintaining a separate fork in Git (such as on GitHub/etc) that has better content (either bug fixes or features) than FSF GNAT or than AdaCore GPL Community Edition. It does not need to be a superset of AdaCore's features; importation of some AdaCore advances can lag by months. Rather the fork must contain content that is respectable in its own right as sought-after bug fixes or sought-after features that cannot be obtained (for now) elsewhere. Your clout would come from code that works, not from a name or from an affiliation. To do this, this new group would need to be prepared to maintain a fork of FSF GNAT for a long term, analogous to back in the mid-1990s when Lucid XEmacs added X Windows support to a fork of GNU Emacs, which eventually pressured GNU Emacs to follow XEmacs's leadership. (Note however that Lucid Software went bankrupt during that effort, so there is that.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 13:56 ` Dan'l Miller @ 2018-08-25 16:00 ` patrick 0 siblings, 0 replies; 55+ messages in thread From: patrick @ 2018-08-25 16:00 UTC (permalink / raw) I have two disabled kids and a sickly wife, she dropped to 82lbs last year. I home school most of the time and work whenever I can. I am in no position to become a one man Adacore. I can study the code base and make a few patches if I get lots and lots of help. I think the original goals for the group are within reason and should not be expanded until they are proven successful ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 12:27 Studying and Maintaining GNAT, Is There Any Interest in a New Group? patrick 2018-08-25 13:56 ` Dan'l Miller @ 2018-08-25 16:16 ` Luke A. Guest 2018-08-25 17:42 ` patrick 2018-08-25 16:43 ` Jeffrey R. Carter 2 siblings, 1 reply; 55+ messages in thread From: Luke A. Guest @ 2018-08-25 16:16 UTC (permalink / raw) The issues are: 1) GCC isn’t the nicest to work with. 2) It’s most likely that AdaCore won’t merge your stuff in. 3) starting from Ada95 and not Ada 2012 is a mistake. 4) a lot of people are finding that they would rather: a) Start a new compiler, or b) Start a new language derived from Ada. You would better off contributing to 4a. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 16:16 ` Luke A. Guest @ 2018-08-25 17:42 ` patrick 2018-08-25 19:25 ` Simon Wright 0 siblings, 1 reply; 55+ messages in thread From: patrick @ 2018-08-25 17:42 UTC (permalink / raw) Hi Luke I was wondering if the patches came from a group, whether the GCC people would accept them without or without Adacore. I know what trouble you have had with GCC and trying to get GNAT ported over to ARM many years ago. However, could it be safe to say that most of the bugs are in the runtime and not in the code generation? So please forget what I was saying about forking an old version of GNAT, looks like a really bad idea as it pretty much looks like it was bolted on without any consultation from the GCC people. Thanks ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 17:42 ` patrick @ 2018-08-25 19:25 ` Simon Wright 2018-08-25 20:24 ` patrick ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Simon Wright @ 2018-08-25 19:25 UTC (permalink / raw) patrick@spellingbeewinnars.org writes: > I was wondering if the patches came from a group, whether the GCC > people would accept them without or without Adacore. I'm far from expert on GCC procedures, but all three of the Ada front-end maintainers (see [1]) are AdaCore employees, and I don't think you're going to get approval for updates to Ada internals from anyone else. If it's OS-related (I see some of this because Darwin) you stand more chance. [1] https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS > I know what trouble you have had with GCC and trying to get GNAT > ported over to ARM many years ago. That was very frustrating. When others (including me) joined in with more evidence things improved. But it can be hard to get the evidence, particularly for rare happenings; I'm convinced there's a bug in the bare-board RTS related to an interrupt occuring during a protected entry, reported almost a year ago, no resolution yet so far as I know. > However, could it be safe to say that most of the bugs are in the > runtime and not in the code generation? When a new compiler release is being made, almost all the bugs will be in the compiler; the RTS is pretty stable. The interface to the RTS can change a bit (for Cortex GNAT RTS, GCC7->GCC8 involved a minor change to the way tagged types are handled, and how secondary stacks are allocated). ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 19:25 ` Simon Wright @ 2018-08-25 20:24 ` patrick 2018-08-25 21:48 ` Luke A. Guest 2018-08-27 17:35 ` Shark8 2018-08-25 21:17 ` Luke A. Guest 2018-08-25 23:16 ` Paul Rubin 2 siblings, 2 replies; 55+ messages in thread From: patrick @ 2018-08-25 20:24 UTC (permalink / raw) Hi Simon The Adacore gatekeepers thing just doesn't really bother me, we could distribute patched versions and the GCC people would eventually catch on if the Adacore guys were blocking good code. However I am discouraged with what you are saying about the bugs being on the compiler side and not so much in the RTS. The runtime is well commented and is mostly Ada. I could see myself understanding this and making patches at some point but GCC is one of the most complex pieces of software ever produced. It's totally out of my league. I am not sure what to do? I don't even know what the a4 project is that Luke spoke of and Byron has not had a commit in over a year and is a massive undertaking. What will GNAT look like in 5 years? :( Doesn't seem worth including in the instrumentation control software I am slowly-slowly writing. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 20:24 ` patrick @ 2018-08-25 21:48 ` Luke A. Guest 2018-08-25 21:53 ` patrick ` (2 more replies) 2018-08-27 17:35 ` Shark8 1 sibling, 3 replies; 55+ messages in thread From: Luke A. Guest @ 2018-08-25 21:48 UTC (permalink / raw) <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. > I don't even know what the a4 project is I did make a list with option numbers, I said 4a, which was to start a new compiler. > that Luke spoke of and Byron has not had a commit in over a year and is a > massive undertaking. Which is one reason to start designing a new language which was 4b. > What will GNAT look like in 5 years? :( Doesn't seem worth including in > the instrumentation control software I am slowly-slowly writing. Who knows? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 21:48 ` Luke A. Guest @ 2018-08-25 21:53 ` patrick 2018-08-25 22:05 ` Luke A. Guest 2018-08-26 19:54 ` Dan'l Miller 2018-08-27 9:37 ` Simon Wright 2 siblings, 1 reply; 55+ messages in thread From: patrick @ 2018-08-25 21:53 UTC (permalink / raw) Ah, I get it, sorry Luke, bit dense here today..... I can't start an Ada compiler but I have a suggestion if someone wants to. Look at GnuCOBOL. It's very plain-jane, run of the mill in a lot of ways. It uses bison/flex for the compiler. It generates C code. It does not have enough comments but it is a good compiler. I know everybody hates C here but I believe generated C can be safe. The runtime could still be written in Ada with just the entry points being C friendly. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 21:53 ` patrick @ 2018-08-25 22:05 ` Luke A. Guest 0 siblings, 0 replies; 55+ messages in thread From: Luke A. Guest @ 2018-08-25 22:05 UTC (permalink / raw) <patrick@spellingbeewinnars.org> wrote: > Ah, I get it, sorry Luke, bit dense here today..... > > I can't start an Ada compiler but I have a suggestion if someone wants to. > > Look at GnuCOBOL. > > It's very plain-jane, run of the mill in a lot of ways. It uses > bison/flex for the compiler. It generates C code. It does not have enough > comments but it is a good compiler. A new compiler needs a radical new design. > > I know everybody hates C here but I believe generated C can be safe. The > runtime could still be written in Ada with just the entry points being C friendly. > Ada can import and export C fine. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 21:48 ` Luke A. Guest 2018-08-25 21:53 ` patrick @ 2018-08-26 19:54 ` Dan'l Miller 2018-08-26 20:14 ` Dan'l Miller ` (2 more replies) 2018-08-27 9:37 ` Simon Wright 2 siblings, 3 replies; 55+ messages in thread From: Dan'l Miller @ 2018-08-26 19:54 UTC (permalink / raw) 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: 1) front-end proper: lack of fidelity (to the _LRM_ or to nuanced explanations in the _AARM_) in the Ada-language semantic-adornment of the AST and 2) lack of fidelity in the GIGI tree-transducer middle layer (which might be truly one-of-a-kind unique to GNAT) effectively •outside• the Ada-language-source-code front-end proper and the GENERIC/GIMPLE/RTL back-end proper: Between a) the Ada-language semantic-tree in the written-in-Ada front-end proper and b) the GCC GENERIC/GIMPLE/RTL back-end that is shared among all GCC languages, there exists the GIGI () tree-transducer that observes snippets of Ada-front-end's semantically-adorned AST to then instantiate the analogous C/C++-language semantics in that branch of the GENERIC/GIMPLE's back-end semantic tree. There are 2 areas where GNAT can easily make a mistake: 1) misinterpret (or malenforce) the normative _LRM_ and/or the nuanced explanations in the _AARM_ in the Ada semantically-adorned AST written in Ada language or 2) mistranscribe the ‘equivalent‘ C/C++ semantics in GENERIC/GIMPLE via the GIGI tree transducer, written in C language. Just like beauty, ‘equivalent’ degenerates to: equivalent is in the eye of the beholder. (And the human being of high IQ has a bigger eye-of-the-beholder than GIGI's observation of mere subset of the Ada AST. GIGI's eye-of-the-beholder naturally has tunnel vision.) 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 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 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 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.) Although Figure 1.1 is the front-end/back-end diagram that most people hold in their head (and dear to their heart) from a compiler-construction textbook, I find Figure 1.2 to much more lucidly reveal GNAT's inner workings in a nutshell for repeated reference in the mind's eye: https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#SECTION03120000000000000000 It is not entirely clear (to me) what GIGI stands for, btw. One of the “G”s could stand for GNAT; the other could stand for GENERIC or GIMPLE. One of the “I”s could stand for instantiation (as in instantiating a snippet/extract of the Ada AST into GENERIC/GIMPLE's C-language tree). One guess: GNAT-Internal GENERIC/GIMPLE Instatiator. Perhaps only the original designers of GIGI know for sure: Robert Dewar, RWS, perhaps Edmond Schonberg. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-26 19:54 ` Dan'l Miller @ 2018-08-26 20:14 ` Dan'l Miller 2018-08-26 22:52 ` Lucretia 2018-08-27 21:18 ` Randy Brukardt 2 siblings, 0 replies; 55+ messages in thread From: Dan'l Miller @ 2018-08-26 20:14 UTC (permalink / raw) On Sunday, August 26, 2018 at 2:54:11 PM UTC-5, Dan'l Miller wrote: > Perhaps only the original designers of GIGI know for sure: Robert Dewar, RWS, perhaps Edmond > Schonberg. RMS, sorry, Mr. Stallman, if you ever read this. (W and M are next to each other on my Dvorak-layout keyboard.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-26 19:54 ` Dan'l Miller 2018-08-26 20:14 ` Dan'l Miller @ 2018-08-26 22:52 ` Lucretia 2018-08-27 2:38 ` Dan'l Miller 2018-08-27 21:27 ` Randy Brukardt 2018-08-27 21:18 ` Randy Brukardt 2 siblings, 2 replies; 55+ messages in thread From: Lucretia @ 2018-08-26 22:52 UTC (permalink / raw) 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. < removed rambling > > 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? >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. >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. 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. >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???? < removed > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-26 22:52 ` Lucretia @ 2018-08-27 2:38 ` Dan'l Miller 2018-08-27 14:46 ` Lucretia 2018-08-27 21:27 ` Randy Brukardt 1 sibling, 1 reply; 55+ messages in thread From: Dan'l Miller @ 2018-08-27 2:38 UTC (permalink / raw) 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?) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 2:38 ` Dan'l Miller @ 2018-08-27 14:46 ` Lucretia 2018-08-27 15:42 ` Dan'l Miller 0 siblings, 1 reply; 55+ messages in thread From: Lucretia @ 2018-08-27 14:46 UTC (permalink / raw) On Monday, 27 August 2018 03:38:32 UTC+1, Dan'l Miller wrote: > > 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. You don't seem to understand how compilers or GCC is structured. There is no weird 3rd layer. Compilers use multiple intermediate representations starting with an asbstract syntax tree, the passes take in the AST and modify it or create a new tree/IR until it gets to the point where code generation can take place. That's essentially it Source Language -> Front-end -> AST -> IR -> IR -> .. -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable > > > 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. Why use 1 word when 50 will do, right? > > 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. No, see above, you always need that, because that's what compilers do. All compilers have language neutral IR's, your front end has to convert from source language to that IR, whether it's GCC's GENERIC/GIMPLE or LLVM or Firm. > I seem to recall an unrelenting general pox on all historical-Ada houses as the overall gist from you. Nope, I said that there is literally no point in trying to reimplement the same software which people didn't like at the time, repeating history, i.e. the source stored as an IR in a database. People didn't want it then, they ain't gonna want it now because getting source in and out of a DB is a pain, yes I know that's what happens with source control, but that's the way it is. > 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?) https://gcc.gnu.org/onlinedocs/gccint/index.html <<- the book you need to read to understand the internals of GCC, it's not an easy or nice read. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 14:46 ` Lucretia @ 2018-08-27 15:42 ` Dan'l Miller 0 siblings, 0 replies; 55+ messages in thread From: Dan'l Miller @ 2018-08-27 15:42 UTC (permalink / raw) On Monday, August 27, 2018 at 9:46:22 AM UTC-5, Lucretia wrote: > On Monday, 27 August 2018 03:38:32 UTC+1, Dan'l Miller wrote: > > > > 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. > > You don't seem to understand how compilers or GCC is structured. There is no weird 3rd layer. > > Compilers use multiple intermediate representations starting with an asbstract syntax tree, the passes > take in the AST and modify it or create a new tree/IR until it gets to the point where code generation can > take place. That's essentially it > > Source Language -> Front-end -> AST -> IR -> IR -> .. -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable And there is where you made your mistake. That is in fact the bland non-innovative straight-from-the-textbook layering for C/C++ in GCC and many other languages' compilers. Instead for GNAT the correction to your diagram looks like this: Ada source Language -> Ada front-end written in Ada -> AdaAST from raw syntax repeatedly repeatedly repeatedly repeatedly traversed to adorn the AdaAST with Ada semantic adornments -> ••C/C++ semantic tree•• -> IR -> IR -> … -> IR -> Codegen -> Assembly code -> Assembler -> Machine code -> Linker -> Executable or DLL What is peculiar to GNAT is tree transduction from Ada semantics to C/C++ semantics. This was Dewar's & RMS's (& Schonberg's?) et. al.'s clever trick in 1993 to make Ada compatible with GCC's pre-existing design: transduce the Ada front-end's semantics tree into the C/C++ •front•-end's C/C++ semantics tree (after, via repeated repeated repeated repeated traversals, preserving the •tree• structure for representing semantics instead of most prior Ada compilers' semantics-DAG, because tree-to-tree transduction is difficult enough, whereas DAG-to-tree transduction is much more impractical). As I said at the outset, the very nature of this discussion risks accusations of quibbling what is and is not so-called IR in the so-called back-end. ('Tis funny that you discounted the existence of the risk of quibbling over where the boundary between front-end & back-end precisely falls in GCC and then launched full-throttle right into that predicted quibbling.) Personally, for the GCC C/C++ compiler, I place the authoring of the C/C++ semantic tree in the front-end, not the back-end, because, well, C/C++ semantics is a property of C/C++ language standardization. GNAT has a clever rear-of-(Ada-)front-end-to-rear-of(-C/C++)-front-end transduction that is not commonplace in most other compilers. All of your diagram's stages are to incrementally •lower• layers. GNAT has—in addition to all that—a •lateral• transduction to the output of another language's (C/C++'s) •front•-end. Even if you insist on quibbling that the authoring of the C/C++ semantics tree is in the back-end in GCC's C/C++ compiler, GNAT has an additional semantic-tree-to-semantic-tree transduction that is absent in GCC's C/C++ compiler. GCC's C/C++ compiler has exactly one semantics-tree, not two, regardless of whether one categorizes it as front-end or back-end. > Why use 1 word when 50 will do, right? Because in as little as one word, you get it factually incorrect. Then it requires a well-worded progression of higher thought to untangle & dissect the incorrectness lucidly for all readers to understand the finer points imbued throughout the correction. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-26 22:52 ` Lucretia 2018-08-27 2:38 ` Dan'l Miller @ 2018-08-27 21:27 ` Randy Brukardt 2018-08-28 7:26 ` Dmitry A. Kazakov 2018-08-29 3:02 ` Paul Rubin 1 sibling, 2 replies; 55+ messages in thread From: Randy Brukardt @ 2018-08-27 21:27 UTC (permalink / raw) "Lucretia" <laguest9000@googlemail.com> wrote in message news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... ... >I never said anything about not learning from DIANA, I said don't >implement it. 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. Fitting OO into a compiler design could very easily turn into a nightmare of required overriding routines, making it very painful to add new kinds of nodes. I used a design like that in the Claw Builder, and the OO parts gummed up the works to the extent that modification is difficult. (Especially if you want to develop code using an agile style, which IMHO is the only successful way to develop code.) Variants and enums in Ada are fully checked (either at compile-time or runtime), so a lot of the advantages of OO are also available using them. (Case completeness checks in particular make it hard to forget to implement something.) And they put the emphasis on the operations rather than on the objects, which can be an advantage for some sorts of code. I don't claim to know the right answer here, but I do know that variants/enums/cases are very useful design tool *in Ada* (not so much in other languages). If one sticks to a strict OO design, you can easily end up working a lot harder than necessary and make maintenance harder than necessary. Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 21:27 ` Randy Brukardt @ 2018-08-28 7:26 ` Dmitry A. Kazakov 2018-08-29 0:16 ` Randy Brukardt 2018-08-29 3:02 ` Paul Rubin 1 sibling, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-08-28 7:26 UTC (permalink / raw) On 2018-08-27 23:27, Randy Brukardt wrote: > "Lucretia" <laguest9000@googlemail.com> wrote in message > news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... > ... >> I never said anything about not learning from DIANA, I said don't >> implement it. 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. > > Fitting OO into a compiler design could very easily turn into a nightmare of > required overriding routines, making it very painful to add new kinds of > nodes. Which is not even possible with variant records. Enumeration types are not extensible and have no classes anyway to allow building a *comparable* case. E.g. type Choice is (A, B); type Var (Mode : Choice) is record case Mode is when A => ... when B => ... end case; end record; 1. How do you extend Choice: type Choice_Ext is new Choice with (C, D, E); -- This not Ada 2. How do you declare Var to accept any descendant of Choice as a discriminant? type Var (Mode : Choice'Class) is record -- This not Ada 3. How do you extend the variant record Var contains? type Var_Plus (Mode : Choice_Ext) is new Var with ? -- This not Ada Since nothing of that kind is possible, what you propose is monolithic design AKA "god-class", when the variant record must know *in advance* all future "extensions", which are extensions no more. You will need to change the declarations of Choice and Var each time and then revisit all client code they appear. And if the above were possible, how would it be different from inheritance as we know it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-28 7:26 ` Dmitry A. Kazakov @ 2018-08-29 0:16 ` Randy Brukardt 2018-08-29 8:20 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Randy Brukardt @ 2018-08-29 0:16 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:pm2tfi$1sv1$1@gioia.aioe.org... > On 2018-08-27 23:27, Randy Brukardt wrote: >> "Lucretia" <laguest9000@googlemail.com> wrote in message >> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... >> ... >>> I never said anything about not learning from DIANA, I said don't >>> implement it. 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. >> >> Fitting OO into a compiler design could very easily turn into a nightmare >> of >> required overriding routines, making it very painful to add new kinds of >> nodes. > > Which is not even possible with variant records. Enumeration types are not > extensible and have no classes anyway to allow building a *comparable* > case. E.g. > > type Choice is (A, B); > type Var (Mode : Choice) is record > case Mode is > when A => ... > when B => ... > end case; > end record; > > 1. How do you extend Choice: Why would you want to? In the case of something like a compiler, there is no reason to extend anything rather than simply modifying it to add the additional capabilities. (That probably goes for anything whose code doesn't have a sane reuse case, which in my experience is a substantial portion of any program.) Certainly in a viable compiler, you have ownership on all of the node types, so modifying them is not the issue it might be with code that is reusable. So to add a new kind of node, you just add additional enumeration literal C to Choice. And the Ada compiler will complain if you forget to add C to any case statements (assuming you avoided the use of "others"). And you'll get runtime errors if you access the wrong variant. It's not even worth the time to try to find everything thta needs to be modified -- I generally just change the things I know about and let compilation and testing (which is easy and extensive for a compiler) find the rest. > type Choice_Ext is new Choice with (C, D, E); -- This not Ada > > 2. How do you declare Var to accept any descendant of Choice as a > discriminant? > > type Var (Mode : Choice'Class) is record -- This not Ada There aren't any descendants of Choice, so this is not a problem. Indeed, I can't imagine any value whatsoever to using extension in this case -- it's really only useful as part of OO designs. > 3. How do you extend the variant record Var contains? > > type Var_Plus (Mode : Choice_Ext) is new Var with ? -- This not Ada Just modify Var with your favorite editor. Not everything benefits from extension. Case in point: I recently added new node types into Janus/Ada for the various Ada 2012 expressions (if expression, raise expression, etc.). This was done by just adding them to the existing node type. There isn't any reason to have them in a separate type (even if you're operating in Ada 95 mode, you could still encounter the nodes if some withed unit was compiled in Ada 2012 mode). It's just additional support. Now, obviously a full OO design would have each node kind supported by a separate type. But even there, you wouldn't separate them from the others (you never want or care about specifically Ada 95 nodes). > Since nothing of that kind is possible, what you propose is monolithic > design AKA "god-class", when the variant record must know *in advance* all > future "extensions", which are extensions no more. Why in advance? One *modifies* code in maintenance; one doesn't tie both hands behind your back! It's hard enough to work on a compiler without making arbitrary rules preventing the modification of types. > You will need to change the declarations of Choice and Var each time and > then revisit all client code they appear. Yes, of course. And Ada makes this easy to do safely. > And if the above were possible, how would it be different from inheritance > as we know it? Inheritance is nearly useless! It helps a tiny bit in code reuse, but it is better still to only write the code once! Having to write dozens of overridding subprograms that don't actually add any semantics is just busy work of no value. Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 0:16 ` Randy Brukardt @ 2018-08-29 8:20 ` Dmitry A. Kazakov 2018-08-29 21:43 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-08-29 8:20 UTC (permalink / raw) On 2018-08-29 02:16, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:pm2tfi$1sv1$1@gioia.aioe.org... >> On 2018-08-27 23:27, Randy Brukardt wrote: >>> "Lucretia" <laguest9000@googlemail.com> wrote in message >>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... >>> ... >>>> I never said anything about not learning from DIANA, I said don't >>>> implement it. 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. >>> >>> Fitting OO into a compiler design could very easily turn into a nightmare >>> of required overriding routines, making it very painful to add new kinds of >>> nodes. >> >> 1. How do you extend Choice: > > Why would you want to? In the case of something like a compiler, there is no > reason to extend anything rather than simply modifying it to add the > additional capabilities. Which makes the initial claim void. There is no nightmare and nothing to override what is not known in advance. For each "when" of the variant case there is an "override" in the inheritance scenario. If you know all "whens" you also know all "overrides". >> Since nothing of that kind is possible, what you propose is monolithic >> design AKA "god-class", when the variant record must know *in advance* all >> future "extensions", which are extensions no more. > > Why in advance? One *modifies* code in maintenance; one doesn't tie both > hands behind your back! It's hard enough to work on a compiler without > making arbitrary rules preventing the modification of types. That is the exact meaning of "in advance": before the final version of the program unit gets ready all variants must be known. >> You will need to change the declarations of Choice and Var each time and >> then revisit all client code they appear. > > Yes, of course. And Ada makes this easy to do safely. Mostly yes, but the distributed overhead of maintenance is still there and it is no so safe as advertised. Consider the client code: if Current.Token = Integer_Token then -- Do something else -- Do something else end if; Here Integer_Token was used in the meaning "scalar". Later on somebody adds Float_Token and boom, it meant to be "scalar"! Even if replaced by case it is still could be unsafe if subtypes used: case Current.Token is when Scalar_Tokens => -- A subtype with Integer_Token in it when others => end case; You must remember to make the subtype Scalar_Tokens covering the newly added Float_Token or else you get an intractable bug. Note that inheritance would handle this safely. It will be: Current.Token.Do_Something; -- A dispatching call override Do_Something would be abstract must-be-overridden for Float_Token. >> And if the above were possible, how would it be different from inheritance >> as we know it? > > Inheritance is nearly useless! It helps a tiny bit in code reuse, but it is > better still to only write the code once! Having to write dozens of > overridding subprograms that don't actually add any semantics is just busy > work of no value. It helps massively, especially interfaces, of course only when used properly during analysis and design phase in order to describe abstraction. One should use the strengths of typing instead of working around them. Variant records in place of interfaces is a path leading to weak typing. I don't say that one should never use variant records, I say that one should not misuse them. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 8:20 ` Dmitry A. Kazakov @ 2018-08-29 21:43 ` Randy Brukardt 2018-08-30 7:55 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Randy Brukardt @ 2018-08-29 21:43 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:pm5l0r$dek$1@gioia.aioe.org... > On 2018-08-29 02:16, Randy Brukardt wrote: >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:pm2tfi$1sv1$1@gioia.aioe.org... >>> On 2018-08-27 23:27, Randy Brukardt wrote: >>>> "Lucretia" <laguest9000@googlemail.com> wrote in message >>>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... >>>> ... >>>>> I never said anything about not learning from DIANA, I said don't >>>>> implement it. 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. >>>> >>>> Fitting OO into a compiler design could very easily turn into a >>>> nightmare >>>> of required overriding routines, making it very painful to add new >>>> kinds of >>>> nodes. >>> >>> 1. How do you extend Choice: >> >> Why would you want to? In the case of something like a compiler, there is >> no >> reason to extend anything rather than simply modifying it to add the >> additional capabilities. > > Which makes the initial claim void. There is no nightmare and nothing to > override what is not known in advance. For each "when" of the variant case > there is an "override" in the inheritance scenario. If you know all > "whens" you also know all "overrides". Surely you "know" them; my point is that there is an incredible amount of busy-work needed to write them (as opposed to just modifying the handful of places that need that). For instance, one has to write tree-walking code into every override, as there is no good way to do that with inheritance (the override has to make a dispatching call on itself on the child mode(s)). The only way to do that with though inheritance is to move all of the tree-walking stuff outside of the OO operations (as is done in the tree container) -- but then you are no longer using strong typing on the children -- the number and kinds of the children have to be checked with manual code. >>> Since nothing of that kind is possible, what you propose is monolithic >>> design AKA "god-class", when the variant record must know *in advance* >>> all >>> future "extensions", which are extensions no more. >> >> Why in advance? One *modifies* code in maintenance; one doesn't tie both >> hands behind your back! It's hard enough to work on a compiler without >> making arbitrary rules preventing the modification of types. > > That is the exact meaning of "in advance": before the final version of the > program unit gets ready all variants must be known. Umm, we're talking about a compiler, and there never is a "final" version of a compiler. Unless it is dead where no one cares anymore. (That's true of most decent-sized systems.) I might have a release version of Janus/Ad today, but there will be another version next year and undoubtably that will require node changes. (Indeed, it must, since I forgot to make qualified expressions a "name" last time around. That means qualified expressions need components for indexing and selection, and means shuffling variants about to avoid duplication.) >>> You will need to change the declarations of Choice and Var each time and >>> then revisit all client code they appear. >> >> Yes, of course. And Ada makes this easy to do safely. > > Mostly yes, but the distributed overhead of maintenance is still there and > it is no so safe as advertised. Consider the client code: > > if Current.Token = Integer_Token then > -- Do something > else > -- Do something else > end if; > > Here Integer_Token was used in the meaning "scalar". Later on somebody > adds Float_Token and boom, it meant to be "scalar"! Sure, but OO doesn't really help here: most properties aren't strictly tree-like. For instance, many type categories don't follow inheritance rules (limited being the obvious example). > Even if replaced by case it is still could be unsafe if subtypes used: > > case Current.Token is > when Scalar_Tokens => -- A subtype with Integer_Token in it > when others => > end case; > > You must remember to make the subtype Scalar_Tokens covering the newly > added Float_Token or else you get an intractable bug. As noted before, use of "others" should be discouraged in case statements on enumerations. That's an important item in our style guide; a bigger organization probably would include it in their tool-based style checks. If you had avoided "others", you'd get a compile-time error when Float_Token was added. I take a lot of advantage of that Ada feature! > Note that inheritance would handle this safely. It will be: > > Current.Token.Do_Something; -- A dispatching call override > > Do_Something would be abstract must-be-overridden for Float_Token. Sure, but that's what's maddening about using OOP in this way. You have to define and implement *every* such operation that way for a new node before anything can be done (even compiling the changed program). There are likely to be hundreds of such operations for a compiler (certainly dozens). That is very much like monolithic waterfall development -- there is nothing agile about it. I try to keep the compiler compiled almost all of the time when doing development, even when making major changes like new node kinds. Compile-time errors tend to get eliminated first. That's in part because code that isn't compilable shouldn't be checked in, and moreover we always need to be able to make fixes for customers. The time while the compiler isn't compilable is a risk period. If instead you use some tool to make an empty set of TBDs for all of these routines, now you've totally eliminated any compiler-based help (all of the needed routines exist, they just don't *work*) and you have exactly the same need for testing that you would have had using a variant. So you've gained nothing. >>> And if the above were possible, how would it be different from >>> inheritance >>> as we know it? >> >> Inheritance is nearly useless! It helps a tiny bit in code reuse, but it >> is >> better still to only write the code once! Having to write dozens of >> overridding subprograms that don't actually add any semantics is just >> busy >> work of no value. > > It helps massively, especially interfaces, of course only when used > properly during analysis and design phase in order to describe > abstraction. One should use the strengths of typing instead of working > around them. Variant records in place of interfaces is a path leading to > weak typing. I don't say that one should never use variant records, I say > that one should not misuse them. I use strong typing to ensure that nodes don't get mixed with symbols or with memory allocation record or many other things. I don't see any point in treating nodes as different types. Spending a lot of extra time doing analysis to try to bring structure where there is little natural structure is wasteful at best. And interfaces are only useful for true code reuse (across disparite systems). Other than that, the percentage of times when you have more than one instance of an interface approaches zero. In that case, an interface only adds overhead and busy-work. Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 21:43 ` Randy Brukardt @ 2018-08-30 7:55 ` Dmitry A. Kazakov 2018-08-30 23:25 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-08-30 7:55 UTC (permalink / raw) On 2018-08-29 23:43, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:pm5l0r$dek$1@gioia.aioe.org... >> On 2018-08-29 02:16, Randy Brukardt wrote: >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:pm2tfi$1sv1$1@gioia.aioe.org... >>>> On 2018-08-27 23:27, Randy Brukardt wrote: >>>>> "Lucretia" <laguest9000@googlemail.com> wrote in message >>>>> news:1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com... >>>>> ... >>>>>> I never said anything about not learning from DIANA, I said don't >>>>>> implement it. 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. >>>>> >>>>> Fitting OO into a compiler design could very easily turn into a >>>>> nightmare >>>>> of required overriding routines, making it very painful to add new >>>>> kinds of >>>>> nodes. >>>> >>>> 1. How do you extend Choice: >>> >>> Why would you want to? In the case of something like a compiler, there is >>> no >>> reason to extend anything rather than simply modifying it to add the >>> additional capabilities. >> >> Which makes the initial claim void. There is no nightmare and nothing to >> override what is not known in advance. For each "when" of the variant case >> there is an "override" in the inheritance scenario. If you know all >> "whens" you also know all "overrides". > > Surely you "know" them; my point is that there is an incredible amount of > busy-work needed to write them (as opposed to just modifying the handful of > places that need that). > > For instance, one has to write tree-walking code into every override, as > there is no good way to do that with inheritance (the override has to make a > dispatching call on itself on the child mode(s)). The only way to do that > with though inheritance is to move all of the tree-walking stuff outside of > the OO operations (as is done in the tree container) -- but then you are no > longer using strong typing on the children -- the number and kinds of the > children have to be checked with manual code. This I don't understand. Why tree operations cannot be primitive and/or class-wide? As a general observation, anything you can do with subtypes of a single type you can also do with a class of a types hierarchy. [There could be some obstacles regarding indefinite vs definite types, but they usually apply to both designs.] >>>> Since nothing of that kind is possible, what you propose is monolithic >>>> design AKA "god-class", when the variant record must know *in advance* >>>> all >>>> future "extensions", which are extensions no more. >>> >>> Why in advance? One *modifies* code in maintenance; one doesn't tie both >>> hands behind your back! It's hard enough to work on a compiler without >>> making arbitrary rules preventing the modification of types. >> >> That is the exact meaning of "in advance": before the final version of the >> program unit gets ready all variants must be known. > > Umm, we're talking about a compiler, and there never is a "final" version of > a compiler. Final = deployed, of course. >>>> You will need to change the declarations of Choice and Var each time and >>>> then revisit all client code they appear. >>> >>> Yes, of course. And Ada makes this easy to do safely. >> >> Mostly yes, but the distributed overhead of maintenance is still there and >> it is no so safe as advertised. Consider the client code: >> >> if Current.Token = Integer_Token then >> -- Do something >> else >> -- Do something else >> end if; >> >> Here Integer_Token was used in the meaning "scalar". Later on somebody >> adds Float_Token and boom, it meant to be "scalar"! > > Sure, but OO doesn't really help here: most properties aren't strictly > tree-like. For instance, many type categories don't follow inheritance rules > (limited being the obvious example). [Non-]limited should have been an interface. There is nothing in it that is not. Non-limited = have copying operations and constructors. [Requires MD] Same applies to by-reference vs. by-copy. By-reference = has identity. Most Ada bells and whistles could be broken down into well-defined interfaces, which should be the goal of the language future changes. >> Note that inheritance would handle this safely. It will be: >> >> Current.Token.Do_Something; -- A dispatching call override >> >> Do_Something would be abstract must-be-overridden for Float_Token. > > Sure, but that's what's maddening about using OOP in this way. You have to > define and implement *every* such operation that way for a new node before > anything can be done (even compiling the changed program). Exactly. This is called being typed. Operations do not exist without types. The design with case-statements spread all over the client code is untyped because chunks of client code under "whens" are not attributed to any type, have no contract etc. OO allows us 1. To give a contract to this code 2. To refactor and reuse this code 3. To place it in separate compilation units *related* to the types involved. > There are likely > to be hundreds of such operations for a compiler (certainly dozens). That is > very much like monolithic waterfall development -- there is nothing agile > about it. Here is where MI comes into play. These hundreds of operations belong to different interfaces. Tree manipulation and node semantics must be described separately. > I try to keep the compiler compiled almost all of the time when doing > development, even when making major changes like new node kinds. > Compile-time errors tend to get eliminated first. That's in part because > code that isn't compilable shouldn't be checked in, and moreover we always > need to be able to make fixes for customers. The time while the compiler > isn't compilable is a risk period. > > If instead you use some tool to make an empty set of TBDs for all of these > routines, now you've totally eliminated any compiler-based help (all of the > needed routines exist, they just don't *work*) and you have exactly the same > need for testing that you would have had using a variant. So you've gained > nothing. Morale, do not use crappy tools. Somebody might someday come with a tool that would generate all "whens" in all case statements filled with null- or raise-statement. Would that be a failure of Ada case-statement design? No. If you do that mess on language level (see dynamic predicates), that is the language mess. If you do mess with a tool, well, that is no language problem. >>>> And if the above were possible, how would it be different from >>>> inheritance >>>> as we know it? >>> >>> Inheritance is nearly useless! It helps a tiny bit in code reuse, but it >>> is >>> better still to only write the code once! Having to write dozens of >>> overridding subprograms that don't actually add any semantics is just >>> busy >>> work of no value. >> >> It helps massively, especially interfaces, of course only when used >> properly during analysis and design phase in order to describe >> abstraction. One should use the strengths of typing instead of working >> around them. Variant records in place of interfaces is a path leading to >> weak typing. I don't say that one should never use variant records, I say >> that one should not misuse them. > > I use strong typing to ensure that nodes don't get mixed with symbols or > with memory allocation record or many other things. But you allow mixing nodes freely? That is the problem. In a tree all nodes are same, but there is semantics of what the node represents and you allow mixing that semantics without mapping it onto types. Only one aspect of your design is strongly typed: tree manipulations, BTW, the aspect more or less marginal to computer design. > I don't see any point in > treating nodes as different types. Spending a lot of extra time doing > analysis to try to bring structure where there is little natural structure > is wasteful at best. There might be categories of nodes sharing certain properties and in the end some refactored code. You cannot describe such things without some form of interface, dynamic (tagged) or static (generics). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-30 7:55 ` Dmitry A. Kazakov @ 2018-08-30 23:25 ` Randy Brukardt 2018-08-31 8:48 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Randy Brukardt @ 2018-08-30 23:25 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:pm87ue$ifg$1@gioia.aioe.org... > On 2018-08-29 23:43, Randy Brukardt wrote: >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message ... >> Surely you "know" them; my point is that there is an incredible amount of >> busy-work needed to write them (as opposed to just modifying the handful >> of >> places that need that). >> >> For instance, one has to write tree-walking code into every override, as >> there is no good way to do that with inheritance (the override has to >> make a >> dispatching call on itself on the child mode(s)). The only way to do that >> with though inheritance is to move all of the tree-walking stuff outside >> of >> the OO operations (as is done in the tree container) -- but then you are >> no >> longer using strong typing on the children -- the number and kinds of the >> children have to be checked with manual code. > > This I don't understand. Why tree operations cannot be primitive and/or > class-wide? They are primitive. That's what forces writing the traversal code into every operation. Consider the following node: type Root_Node is abstract tagged null record; type Expr_Tree_Access is access Root_Node'Class; procedure Fold (Expr : in out Root_Node); -- Fold the tree. type Binop is new Root_Node with record Kind : Op; Left, Right : Expr_Tree_Access; end record; and the implementation of the Folding operation: overriding procedure Fold (Expr : in out Binop); procedure Fold (Expr : in out Binop) is begin Fold (Expr.Left.all); Fold (Expr.Right.all); -- If Expr.Left and Expr.Right are constants, calculate the folded value. end Fold; This operation has to do recursive (dispatching calls) on the children. And so does every other such operation that gets defined (dozens). You can't write such code separately from the recursive calls without completely losing any typing. (You have to resort to generic formal subprograms or access-to-subprograms to do that, which are very weakly typed techniques.) This gets much more complicated for items that have lists or worse lists-of-lists (like an Ada "name"). > As a general observation, anything you can do with subtypes of a single > type you can also do with a class of a types hierarchy. [There could be > some obstacles regarding indefinite vs definite types, but they usually > apply to both designs.] This is true, you just have to write 3 times as much code to make the OO design work. And you lose the ability to do agile programming, because you have to implement so much new code to add a new node or operation (probably on the order of a week for either in an Ada compiler perspective -- dozens of operations and dozens of node types are needed there). >>>>> Since nothing of that kind is possible, what you propose is monolithic >>>>> design AKA "god-class", when the variant record must know *in advance* >>>>> all >>>>> future "extensions", which are extensions no more. >>>> >>>> Why in advance? One *modifies* code in maintenance; one doesn't tie >>>> both >>>> hands behind your back! It's hard enough to work on a compiler without >>>> making arbitrary rules preventing the modification of types. >>> >>> That is the exact meaning of "in advance": before the final version of >>> the >>> program unit gets ready all variants must be known. >> >> Umm, we're talking about a compiler, and there never is a "final" version >> of >> a compiler. > > Final = deployed, of course. Which is relevant how? It's just a snapshot of a continual evolution. ... >>> Note that inheritance would handle this safely. It will be: >>> >>> Current.Token.Do_Something; -- A dispatching call override >>> >>> Do_Something would be abstract must-be-overridden for Float_Token. >> >> Sure, but that's what's maddening about using OOP in this way. You have >> to >> define and implement *every* such operation that way for a new node >> before >> anything can be done (even compiling the changed program). > > Exactly. This is called being typed. Operations do not exist without > types. The design with case-statements spread all over the client code is > untyped because chunks of client code under "whens" are not attributed to > any type, have no contract etc. OO allows us > > 1. To give a contract to this code > 2. To refactor and reuse this code > 3. To place it in separate compilation units *related* to the types > involved. (1) There is no useful contracts for individual nodes -- all of the contracts with any meaning are on the tree as a whole. And it is the state of the nodes, rather than their kinds, which figure mainly into those contracts. (The state being part of the data, not part of the types.) (2) Refactoring isn't any harder with a variant design than it is with a OO design -- I do those sorts of things all of the time. (But not too often, one has to be pretty sure before doing any refactoring that it really will benefit the program -- a lot of the time, such things end up being lateral moves where one problem is fixed, but only by introducing others. Ada, like almost anything real, is not that regular!) (3) We abandoned this at the very beginning of Janus/Ada development -- the reason being that we were running in extremely space limited environments, and we couldn't afford to use extra calls in the code needed for any sort of encapsulation. (Similarly, we used a lot of global variables in early Janus/Ada because they were substantially cheaper the access than local variables on the Z80 machines. We knew better, but couldn't afford to do it right.) While the global variable thing is surely worth stamping out (most of them are gone now, a few persistent ones that are heavily used remain), I'm unconvinced that adding a lot of Ada "goodness" would really work in an Ada compiler environment. You would need so many getter/setter routines that you would be spending 50% of your time adding/fixing them rather than doing anything useful. We've gotten a lot of mileage out of using aggregate assignments to ensure completeness rather than trying to make everything private. As I said that the outset, I'm not sure what the right answer is, or even if there is a right answer. >> There are likely >> to be hundreds of such operations for a compiler (certainly dozens). That >> is >> very much like monolithic waterfall development -- there is nothing agile >> about it. > > Here is where MI comes into play. These hundreds of operations belong to > different interfaces. Tree manipulation and node semantics must be > described separately. As noted above, I don't think that is possible. I certainly couldn't find any way to do it in the Claw Builder (other than using generic formals to to tree walkers -- and generics don't inherit). >> I try to keep the compiler compiled almost all of the time when doing >> development, even when making major changes like new node kinds. >> Compile-time errors tend to get eliminated first. That's in part because >> code that isn't compilable shouldn't be checked in, and moreover we >> always >> need to be able to make fixes for customers. The time while the compiler >> isn't compilable is a risk period. >> >> If instead you use some tool to make an empty set of TBDs for all of >> these >> routines, now you've totally eliminated any compiler-based help (all of >> the >> needed routines exist, they just don't *work*) and you have exactly the >> same >> need for testing that you would have had using a variant. So you've >> gained >> nothing. > > Morale, do not use crappy tools. Somebody might someday come with a tool > that would generate all "whens" in all case statements filled with null- > or raise-statement. Would that be a failure of Ada case-statement design? > No. If you do that mess on language level (see dynamic predicates), that > is the language mess. If you do mess with a tool, well, that is no > language problem. Which does not answer the underlying question: how do you do agile development if adding an operation or new kind of node requires 4 days of coding? ... >>> It helps massively, especially interfaces, of course only when used >>> properly during analysis and design phase in order to describe >>> abstraction. One should use the strengths of typing instead of working >>> around them. Variant records in place of interfaces is a path leading to >>> weak typing. I don't say that one should never use variant records, I >>> say >>> that one should not misuse them. >> >> I use strong typing to ensure that nodes don't get mixed with symbols or >> with memory allocation record or many other things. > > But you allow mixing nodes freely? That is the problem. In a tree all > nodes are same, but there is semantics of what the node represents and you > allow mixing that semantics without mapping it onto types. Only one aspect > of your design is strongly typed: tree manipulations, BTW, the aspect more > or less marginal to computer design. For Ada at least, the only meaningful data structure is the expression tree. We don't care about the individual nodes outside of a handful of tree walking operations. Most everything talks specifically about the tree. The tree does have different states -- but all of the nodes in the tree ought to be in the same state. One could imagine trying to encode the state into the types, but that would require copying/relinking nodes every time there is a state change (since Ada doesn't allow changing tags in existing objects). That would be a massive overhead, and since much of the cost of a compiler is managing nodes (allocation/deallocation/copying/reading/writing), the last thing you would want to do is increase that overhead. >> I don't see any point in >> treating nodes as different types. Spending a lot of extra time doing >> analysis to try to bring structure where there is little natural >> structure >> is wasteful at best. > > There might be categories of nodes sharing certain properties and in the > end some refactored code. You cannot describe such things without some > form of interface, dynamic (tagged) or static (generics). Well, maybe you can't, but I do it all of the time. :-) Maybe I could do it a bit more often, but as I said above, most refactoring is just a waste of time (swapping known problems for new ones). It takes a lot of disipline not to waste time doing such things. In any case, I don't expect ever to agree with you on these points. I think a lot of people take strong typing too far -- but of course the sweet spot is hard to find. There may be an argument for going further than I do, but my experience doesn't show much value to that. Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-30 23:25 ` Randy Brukardt @ 2018-08-31 8:48 ` Dmitry A. Kazakov 2018-08-31 22:42 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-08-31 8:48 UTC (permalink / raw) On 2018-08-31 01:25, Randy Brukardt wrote: > They are primitive. That's what forces writing the traversal code into every > operation. Consider the following node: > type Root_Node is abstract tagged null record; > type Expr_Tree_Access is access Root_Node'Class; > > procedure Fold (Expr : in out Root_Node); -- Fold the tree. > > type Binop is new Root_Node with record > Kind : Op; > Left, Right : Expr_Tree_Access; > end record; > > and the implementation of the Folding operation: > overriding > procedure Fold (Expr : in out Binop); > > procedure Fold (Expr : in out Binop) is > begin > Fold (Expr.Left.all); > Fold (Expr.Right.all); > -- If Expr.Left and Expr.Right are constants, calculate the > folded value. > end Fold; > > This operation has to do recursive (dispatching calls) on the children. And > so does every other such operation that gets defined (dozens). Why isn't Fold class-wide: procedure Fold (Expr : in out Binop'Class) is begin Fold (Expr.Left.all); Fold (Expr.Right.all); Expr.Evaluate; -- This dispatches to the Op's implementation end Fold; BTW, I prefer to fold constants before generating the tree. I.e. when Evaluate is called it returns either a value ("constant" node) or a new "dynamic" node. >> As a general observation, anything you can do with subtypes of a single >> type you can also do with a class of a types hierarchy. [There could be >> some obstacles regarding indefinite vs definite types, but they usually >> apply to both designs.] > > This is true, you just have to write 3 times as much code to make the OO > design work. And you lose the ability to do agile programming, because you > have to implement so much new code to add a new node or operation (probably > on the order of a week for either in an Ada compiler perspective -- dozens > of operations and dozens of node types are needed there). You would possibly save a comparable number of source lines in clients. >>> Umm, we're talking about a compiler, and there never is a "final" version >>> of a compiler. >> >> Final = deployed, of course. > > Which is relevant how? It's just a snapshot of a continual evolution. Each new release is another program. You might kill the whole package next time, the code is not stable. With OO I can have stable pieces of code frozen in separate packages which never change and keep adding volatile code without rewriting everything each time. > ... >>>> Note that inheritance would handle this safely. It will be: >>>> >>>> Current.Token.Do_Something; -- A dispatching call override >>>> >>>> Do_Something would be abstract must-be-overridden for Float_Token. >>> >>> Sure, but that's what's maddening about using OOP in this way. You have >>> to >>> define and implement *every* such operation that way for a new node >>> before >>> anything can be done (even compiling the changed program). >> >> Exactly. This is called being typed. Operations do not exist without >> types. The design with case-statements spread all over the client code is >> untyped because chunks of client code under "whens" are not attributed to >> any type, have no contract etc. OO allows us >> >> 1. To give a contract to this code >> 2. To refactor and reuse this code >> 3. To place it in separate compilation units *related* to the types >> involved. > > (1) There is no useful contracts for individual nodes -- all of the > contracts with any meaning are on the tree as a whole. And it is the state > of the nodes, rather than their kinds, which figure mainly into those > contracts. (The state being part of the data, not part of the types.) But when you fold constants you do that according to the types of the nodes. The question is if you try to map these types onto Ada types or not. > (2) Refactoring isn't any harder with a variant design than it is with a OO > design -- I do those sorts of things all of the time. I find using free subprograms more difficult. They have no natural place to keep in. So I always forget which package holds this or that refactored subprogram and end up with several instances doing basically same thing. > You would need so many getter/setter routines that you > would be spending 50% of your time adding/fixing them rather than doing > anything useful. In my experience getter/setter tend to be stable. My problem is that they pollute package specification. This is one of the reasons why I'd like to have record interfaces: type Getters_Setters is interface record Field_1 : Integer; -- "Virtual" record field ... end record; type T is ... and Getters_Setters with ... The type T need not to contain Field_1 physically. If it does not one should override getter and setter (in the private part). > We've gotten a lot of mileage out of using aggregate > assignments to ensure completeness rather than trying to make everything > private. It was wasting time, IMO. User-defined aggregates would be much simpler to add without burdening the language with dubious rules and counterintuitive constructs. > Which does not answer the underlying question: how do you do agile > development if adding an operation or new kind of node requires 4 days of > coding? I don't buy agile if that means generating false code. When I add an abstract operation I want the compiler to generate error messages the same way it does when a new case choice is added. BTW, I feel uncomfortable about Ada 2005(?) change that a primitive function returning the type need not to be always overridden. > For Ada at least, the only meaningful data structure is the expression tree. > We don't care about the individual nodes outside of a handful of tree > walking operations. Most everything talks specifically about the tree. I'd like to have it reverse, hiding walking and exposing semantics of the nodes. > In any case, I don't expect ever to agree with you on these points. I think > a lot of people take strong typing too far -- but of course the sweet spot > is hard to find. There may be an argument for going further than I do, but > my experience doesn't show much value to that. True, I want to push typing and static verification in general as far as possible. Nothing is too far to me. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-31 8:48 ` Dmitry A. Kazakov @ 2018-08-31 22:42 ` Randy Brukardt 2018-09-02 8:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 55+ messages in thread From: Randy Brukardt @ 2018-08-31 22:42 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:pmavco$u5d$1@gioia.aioe.org... > On 2018-08-31 01:25, Randy Brukardt wrote: > >> They are primitive. That's what forces writing the traversal code into >> every >> operation. Consider the following node: >> type Root_Node is abstract tagged null record; >> type Expr_Tree_Access is access Root_Node'Class; >> >> procedure Fold (Expr : in out Root_Node); -- Fold the tree. >> >> type Binop is new Root_Node with record >> Kind : Op; >> Left, Right : Expr_Tree_Access; >> end record; >> >> and the implementation of the Folding operation: >> overriding >> procedure Fold (Expr : in out Binop); >> >> procedure Fold (Expr : in out Binop) is >> begin >> Fold (Expr.Left.all); >> Fold (Expr.Right.all); >> -- If Expr.Left and Expr.Right are constants, calculate the >> folded value. >> end Fold; >> >> This operation has to do recursive (dispatching calls) on the children. >> And >> so does every other such operation that gets defined (dozens). > > Why isn't Fold class-wide: > > procedure Fold (Expr : in out Binop'Class) is > begin > Fold (Expr.Left.all); > Fold (Expr.Right.all); > Expr.Evaluate; -- This dispatches to the Op's implementation > end Fold; There's not one "evaluate" operation here; there are 6 different phases of tree operations (construction, lookup, resolution, checking, folding, and conversion to low-level IR). Most of these have to be separate because of various Ada rules (for instance, we used to do lookup as part of construction, but it has to be deferred for expressions in pragmas and aspect definitions). One walks the tree at least these times (and more if the tree has to be persisted -- for instance, if it is a default expression in a specification). > BTW, I prefer to fold constants before generating the tree. I.e. when > Evaluate is called it returns either a value ("constant" node) or a new > "dynamic" node. In Ada, you can't do folding until you know what the operations are, and you don't know that until after resolution (that is, "*" could be predefined, which you can fold, or user-defined, which you probably can't fold, and certainly can't treat as static). >>> As a general observation, anything you can do with subtypes of a single >>> type you can also do with a class of a types hierarchy. [There could be >>> some obstacles regarding indefinite vs definite types, but they usually >>> apply to both designs.] >> >> This is true, you just have to write 3 times as much code to make the OO >> design work. And you lose the ability to do agile programming, because >> you >> have to implement so much new code to add a new node or operation >> (probably >> on the order of a week for either in an Ada compiler perspective -- >> dozens >> of operations and dozens of node types are needed there). > > You would possibly save a comparable number of source lines in clients. That wasn't my experience with CBuild, but that's only a single example (and not a compiler, either). >>>> Umm, we're talking about a compiler, and there never is a "final" >>>> version >>>> of a compiler. >>> >>> Final = deployed, of course. >> >> Which is relevant how? It's just a snapshot of a continual evolution. > > Each new release is another program. You might kill the whole package next > time, the code is not stable. With OO I can have stable pieces of code > frozen in separate packages which never change and keep adding volatile > code without rewriting everything each time. Which again is relevant how? You might not have to change some code depending on the code structure, but the number of changes really only matter in true spaggetti code (where everything is everywhere). Expression tree manipulations are only a small part of the compiler (less than 25%, I think). You could make it more by putting statements and declarations into those trees, but that wouldn't buy much and wouldn't add that much code to the tree manipulations, either. A lot of the code is handling the environment (with clauses and the like) as well as symbol table operations. ... >>> 1. To give a contract to this code >>> 2. To refactor and reuse this code >>> 3. To place it in separate compilation units *related* to the types >>> involved. >> >> (1) There is no useful contracts for individual nodes -- all of the >> contracts with any meaning are on the tree as a whole. And it is the >> state >> of the nodes, rather than their kinds, which figure mainly into those >> contracts. (The state being part of the data, not part of the types.) > > But when you fold constants you do that according to the types of the > nodes. The question is if you try to map these types onto Ada types or > not. There's no real types involved here. The actual folding code is quite small, and there's only a handful of node kinds that are even involved. There's simply not enough benefit to extra typing on these things. >> (2) Refactoring isn't any harder with a variant design than it is with a >> OO >> design -- I do those sorts of things all of the time. > > I find using free subprograms more difficult. They have no natural place > to keep in. So I always forget which package holds this or that refactored > subprogram and end up with several instances doing basically same thing. Yes, I agree that's a problem. But it's not a problem with a solution, since almost all compiler operations are cross operations, using symbol table information, expression tree information, and type information to create (three very different and mostly unrelated data structures). Very few of them obviously belong to any particular one, and any choice tends to be arbitrary. ... >> Which does not answer the underlying question: how do you do agile >> development if adding an operation or new kind of node requires 4 days of >> coding? > > I don't buy agile if that means generating false code. When I add an > abstract operation I want the compiler to generate error messages the same > way it does when a new case choice is added. > > BTW, I feel uncomfortable about Ada 2005(?) change that a primitive > function returning the type need not to be always overridden. I do too, but probably for the opposite reason: it's a fragile mechanism tied to a null extension. If you try to program agily, you might very well write the extension first and add the components later. Now you've suddenly got to override a bunch functions that were fine before -- which defeats the purpose of declaring the type first in the first place. This problem is also a substantial one when using generic mix-ins, since the mix-in doesn't know about the functions in question and can't really do so. IMHO, it should work any time all of the components in the extension have well-defined defaults. Then the mix-in case would work with sufficient care, and if you want to force redefinition of everything, just have a component with no default. >> For Ada at least, the only meaningful data structure is the expression >> tree. >> We don't care about the individual nodes outside of a handful of tree >> walking operations. Most everything talks specifically about the tree. > > I'd like to have it reverse, hiding walking and exposing semantics of the > nodes. > >> In any case, I don't expect ever to agree with you on these points. I >> think >> a lot of people take strong typing too far -- but of course the sweet >> spot >> is hard to find. There may be an argument for going further than I do, >> but >> my experience doesn't show much value to that. > > True, I want to push typing and static verification in general as far as > possible. Nothing is too far to me. (:-)) <Grin>. I have a different vision of static verification than you do; I'm primarily focused on static verification of Ada's dynamic checks. (Since that includes pragma Assert and the like, you can verify almost everything this way.) And I want the compiler to do that - not the least because I would like to show that there are other possible visions for Ada compilers than AdaCore's. (And if it gets people to buy more compilers from me, all the better. :-) Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-31 22:42 ` Randy Brukardt @ 2018-09-02 8:02 ` Dmitry A. Kazakov 2018-09-04 22:18 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-09-02 8:02 UTC (permalink / raw) On 2018-09-01 00:42, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:pmavco$u5d$1@gioia.aioe.org... >> On 2018-08-31 01:25, Randy Brukardt wrote: >> >> Why isn't Fold class-wide: >> >> procedure Fold (Expr : in out Binop'Class) is >> begin >> Fold (Expr.Left.all); >> Fold (Expr.Right.all); >> Expr.Evaluate; -- This dispatches to the Op's implementation >> end Fold; > > There's not one "evaluate" operation here; there are 6 different phases of > tree operations (construction, lookup, resolution, checking, folding, and > conversion to low-level IR). For each of them I would decide if that is a primitive or class-wide operation. >> BTW, I prefer to fold constants before generating the tree. I.e. when >> Evaluate is called it returns either a value ("constant" node) or a new >> "dynamic" node. > > In Ada, you can't do folding until you know what the operations are, and you > don't know that until after resolution (that is, "*" could be predefined, > which you can fold, or user-defined, which you probably can't fold, and > certainly can't treat as static). I meant folding universal constants. During/after type resolution one could generate the next tree and fold resolved constants then. >>>>> Umm, we're talking about a compiler, and there never is a "final" >>>>> version of a compiler. >>>> >>>> Final = deployed, of course. >>> >>> Which is relevant how? It's just a snapshot of a continual evolution. >> >> Each new release is another program. You might kill the whole package next >> time, the code is not stable. With OO I can have stable pieces of code >> frozen in separate packages which never change and keep adding volatile >> code without rewriting everything each time. > > Which again is relevant how? To the meaning of "knowing in advance". You basically say that you do not know anything because the program gets sometimes changed. > You might not have to change some code > depending on the code structure, but the number of changes really only > matter in true spaggetti code (where everything is everywhere). Expression > tree manipulations are only a small part of the compiler (less than 25%, I > think). You could make it more by putting statements and declarations into > those trees, but that wouldn't buy much and wouldn't add that much code to > the tree manipulations, either. A lot of the code is handling the > environment (with clauses and the like) as well as symbol table operations. OK, that is basically this: it is not so much code, I can do it quick-and-dirty without much consideration. It is a valid argument in your case because you write and maintain this code all your life and could possibly do it while sleeping. (:-)) But as a general advice it is IMO wrong. > I do too, but probably for the opposite reason: it's a fragile mechanism > tied to a null extension. If you try to program agily, you might very well > write the extension first and add the components later. Now you've suddenly > got to override a bunch functions that were fine before -- which defeats the > purpose of declaring the type first in the first place. I ask what is agile here? The type with null extension is same. The operations are same. What was changed? Looks like useless and mindless activity to me. > This problem is also a substantial one when using generic mix-ins, since the > mix-in doesn't know about the functions in question and can't really do so. > IMHO, it should work any time all of the components in the extension have > well-defined defaults. Then the mix-in case would work with sufficient care, > and if you want to force redefinition of everything, just have a component > with no default. Mix-in is never safe, should be replaced by MI and/or parallel type hierarchy mechanics. > I have a different vision of static verification than you do; I'm primarily > focused on static verification of Ada's dynamic checks. (Since that includes > pragma Assert and the like, you can verify almost everything this way.) It is OK, but low-level. One cannot organize such checks in a way of type checks, which have inheritance, parameter matching, composition of new types. You lose a lot. Not everything can be checked by types, of course. > And > I want the compiler to do that - not the least because I would like to show > that there are other possible visions for Ada compilers than AdaCore's. (And > if it gets people to buy more compilers from me, all the better. :-) It would be great to have a viable alternative to GNAT. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-02 8:02 ` Dmitry A. Kazakov @ 2018-09-04 22:18 ` Randy Brukardt 0 siblings, 0 replies; 55+ messages in thread From: Randy Brukardt @ 2018-09-04 22:18 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:pmg5ec$rr7$1@gioia.aioe.org... > On 2018-09-01 00:42, Randy Brukardt wrote: ... >>> BTW, I prefer to fold constants before generating the tree. I.e. when >>> Evaluate is called it returns either a value ("constant" node) or a new >>> "dynamic" node. >> >> In Ada, you can't do folding until you know what the operations are, and >> you >> don't know that until after resolution (that is, "*" could be predefined, >> which you can fold, or user-defined, which you probably can't fold, and >> certainly can't treat as static). > > I meant folding universal constants. During/after type resolution one > could generate the next tree and fold resolved constants then. Ystill can't fold those in Ada. Consider: A : constant Saturated := 2 + 2; You can't fold "2 + 2" without doing resolution first, since Ada says that a user-defined "+" operator would be used here (which is probably the case for a Saturated type). It's pretty rare that the universal operations get used in Ada code. To fold this expression (assuming a typical implementation for saturated "+"), you'd have resolve the expression, inline the "+" code, and then fold that. ... >> I have a different vision of static verification than you do; I'm >> primarily >> focused on static verification of Ada's dynamic checks. (Since that >> includes >> pragma Assert and the like, you can verify almost everything this way.) > > It is OK, but low-level. One cannot organize such checks in a way of type > checks, which have inheritance, parameter matching, composition of new > types. You lose a lot. Not everything can be checked by types, of course. Well, actually, class-wide preconditions/postconditions do in fact have those characteristics. Of course, you need an OO design to take advantage of that -- but the point is you don't have to do *everything* with types. Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 21:27 ` Randy Brukardt 2018-08-28 7:26 ` Dmitry A. Kazakov @ 2018-08-29 3:02 ` Paul Rubin 2018-08-29 6:18 ` Luke A. Guest 1 sibling, 1 reply; 55+ messages in thread From: Paul Rubin @ 2018-08-29 3:02 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Fitting OO into a compiler design could very easily turn into a nightmare of > required overriding routines, making it very painful to add new kinds of > nodes. I agree with this from a different perspective. I greatly enjoyed Andrew Appel's book "Modern Compiler Implementation in ML" and based on it, if I were to try writing a compiler for real, I'm quite sure I'd use a functional-programming approach if possible, probably in Haskell or maybe Idris, though ML is of course possible too. People interested in writing compilers should check out the book. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 3:02 ` Paul Rubin @ 2018-08-29 6:18 ` Luke A. Guest 2018-08-29 19:00 ` Paul Rubin 0 siblings, 1 reply; 55+ messages in thread From: Luke A. Guest @ 2018-08-29 6:18 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: > "Randy Brukardt" <randy@rrsoftware.com> writes: >> Fitting OO into a compiler design could very easily turn into a nightmare of >> required overriding routines, making it very painful to add new kinds of >> nodes. > > I agree with this from a different perspective. I greatly enjoyed > Andrew Appel's book "Modern Compiler Implementation in ML" and based on > it, if I were to try writing a compiler for real, I'm quite sure I'd use > a functional-programming approach if possible, probably in Haskell or > maybe Idris, though ML is of course possible too. People interested in > writing compilers should check out the book. > I have the C version of that book, bought before I got into Ada. I can see how FP languages help in the construction of the front end of a compiler, but forcing FP on the rest of the compiler where you’re not doing tree walking, I’m not so sure. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 6:18 ` Luke A. Guest @ 2018-08-29 19:00 ` Paul Rubin 2018-08-30 5:54 ` Luke A. Guest 0 siblings, 1 reply; 55+ messages in thread From: Paul Rubin @ 2018-08-29 19:00 UTC (permalink / raw) Luke A. Guest <laguest@archeia.com> writes: > I have the C version of that book, bought before I got into Ada. I can see > how FP languages help in the construction of the front end of a compiler, > but forcing FP on the rest of the compiler where you’re not doing tree > walking, I’m not so sure. It wouldn't have occurred to me that any "forcing" would be involved, since the approach seems very natural. Past the front end there are usually a bunch of IR rewriting passes, and sometimes multiple IR's involving translation steps. Then at the end there is instruction selection, which in the book is done by tree pattern recognition (other approaches are also possible). This paper was pretty impressive, about cleaning up a compilation phase by replacing a traditional data structure with a functional one: https://www.cs.tufts.edu/~nr/pubs/zipcfg.pdf I think I've linked it before, so you may have seen it already. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-29 19:00 ` Paul Rubin @ 2018-08-30 5:54 ` Luke A. Guest 2018-08-30 6:29 ` Paul Rubin 0 siblings, 1 reply; 55+ messages in thread From: Luke A. Guest @ 2018-08-30 5:54 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> wrote: > It wouldn't have occurred to me that any "forcing" would be involved, My issue with FP is forcing recursion everywhere, that’s really unnatural and very difficult to think in, it’s natural for some algorithms but not all. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-30 5:54 ` Luke A. Guest @ 2018-08-30 6:29 ` Paul Rubin 0 siblings, 0 replies; 55+ messages in thread From: Paul Rubin @ 2018-08-30 6:29 UTC (permalink / raw) Luke A. Guest <laguest@archeia.com> writes: > My issue with FP is forcing recursion everywhere, that’s really > unnatural and very difficult to think in, it’s natural for some > algorithms but not all. I'm not sure what you want to use instead. Generally in Haskell one doesn't use much explicit recursion but instead uses functions like map and fold, to operate on collections all at once. If you really want to use something like a while-loop or for-loop, Ocaml has those: https://ocaml.org/learn/tutorials/if_statements_loops_and_recursion.html#For-loops-and-while-loops but it's a pretty safe bet that they are just syntactic sugar for recursive closures. Haskell has some similar library functions that are useful now and then: http://hackage.haskell.org/package/monad-loops-0.4.3/docs/Control-Monad-Loops.html Normally though, you wouldn't write a traditional imperative loop in a functional language, because of the mutating index variable. There are alternate idioms and you get used to them. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-26 19:54 ` Dan'l Miller 2018-08-26 20:14 ` Dan'l Miller 2018-08-26 22:52 ` Lucretia @ 2018-08-27 21:18 ` Randy Brukardt 2 siblings, 0 replies; 55+ messages in thread From: Randy Brukardt @ 2018-08-27 21:18 UTC (permalink / raw) "Dan'l Miller" <optikos@verizon.net> wrote in message news:3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com... ... >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: ... For what is't worth, based on my lengthy experience with Ada, bugs are most often errors of omission rather than errors of commission. That goes for every Ada compiler that's I've worked with (and we worked with most of them when Claw was being developed in the early days of Ada 95 support). Same seems to be the case when looking at new ACATS tests. Errors of omission are failures to implement a Legality Rule, or a runtime check, or to implement some needed special case within the compiler. Implementing actually the wrong thing is much less likely. The ACATS of course can help with missing rules and checks; it's not as useful for missing special cases (as those tend to be compiler-specific). Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 21:48 ` Luke A. Guest 2018-08-25 21:53 ` patrick 2018-08-26 19:54 ` Dan'l Miller @ 2018-08-27 9:37 ` Simon Wright 2018-08-27 16:54 ` Bill Findlay 2 siblings, 1 reply; 55+ messages in thread From: Simon Wright @ 2018-08-27 9:37 UTC (permalink / raw) Luke A. Guest <laguest@archeia.com> writes: > <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. There are also bugs in the front/back end interface, which can be triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed quickly (IME). And there are bugs in the backend; e.g. currently some problems with LTO/Darwin. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 9:37 ` Simon Wright @ 2018-08-27 16:54 ` Bill Findlay 2018-08-27 17:42 ` Shark8 2018-09-01 7:41 ` Simon Wright 0 siblings, 2 replies; 55+ messages in thread From: Bill Findlay @ 2018-08-27 16:54 UTC (permalink / raw) On 27 Aug 2018, Simon Wright wrote (in article <lysh30kv4l.fsf@pushface.org>): > Luke A. Guest <laguest@archeia.com> writes: > > > <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. > > There are also bugs in the front/back end interface, which can be > triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed > quickly (IME). > > And there are bugs in the backend; e.g. currently some problems with > LTO/Darwin. Could you say more about that, Simon? It might explain some difficulties I have been experiencing. -- Bill Findlay ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 16:54 ` Bill Findlay @ 2018-08-27 17:42 ` Shark8 2018-08-31 21:23 ` Robert A Duff 2018-09-01 7:41 ` Simon Wright 1 sibling, 1 reply; 55+ messages in thread From: Shark8 @ 2018-08-27 17:42 UTC (permalink / raw) On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote: > On 27 Aug 2018, Simon Wright wrote: > > > Luke A. Guest writes: > > > > > patrick 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愀 more the bugs are in the Ada front end, not the GCC backend, > > > which is the codegen. > > > > There are also bugs in the front/back end interface, which can be > > triggered by unusual Ada usages. But, (a) unusual, (b) when found, fixed > > quickly (IME). > > > > And there are bugs in the backend; e.g. currently some problems with > > LTO/Darwin. > > Could you say more about that, Simon? > It might explain some difficulties I have been experiencing. > > -- > Bill Findlay Well, one bug that seems to recur frequently is mishandling of RENAMES, and not obscure renamings either, things like attribute renaming: Length : Natural renames Some_Array'Length; (Though they might have special-cased this particular one.) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 17:42 ` Shark8 @ 2018-08-31 21:23 ` Robert A Duff 2018-08-31 22:51 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: Robert A Duff @ 2018-08-31 21:23 UTC (permalink / raw) Shark8 <onewingedshark@gmail.com> writes: > On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote: >> On 27 Aug 2018, Simon Wright wrote: >> > And there are bugs in the backend; e.g. currently some problems with >> > LTO/Darwin. >> >> Could you say more about that, Simon? >> It might explain some difficulties I have been experiencing. > Well, one bug that seems to recur frequently is mishandling of RENAMES, and not obscure renamings either, things like attribute renaming: > Length : Natural renames Some_Array'Length; That's illegal, because Some_Array'Length denotes a value, not an object, so you can't use it like that in an object_renaming_declaration. GNAT correctly detects this error. I don't see any mishandling here. Am I missing something? I would prefer to allow the above, but that's a language issue, not a compiler issue. And it's certainly not an issue specific to the back end. > (Though they might have special-cased this particular one.) Not sure what you mean by that. - Bob ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-31 21:23 ` Robert A Duff @ 2018-08-31 22:51 ` Randy Brukardt 2018-09-01 19:42 ` Robert A Duff 2018-09-02 10:11 ` AdaMagica 0 siblings, 2 replies; 55+ messages in thread From: Randy Brukardt @ 2018-08-31 22:51 UTC (permalink / raw) "Robert A Duff" <bobduff@TheWorld.com> wrote in message news:wcc5zzqtels.fsf@TheWorld.com... > Shark8 <onewingedshark@gmail.com> writes: > >> On Monday, August 27, 2018 at 10:54:48 AM UTC-6, Bill Findlay wrote: >>> On 27 Aug 2018, Simon Wright wrote: >>> > And there are bugs in the backend; e.g. currently some problems with >>> > LTO/Darwin. >>> >>> Could you say more about that, Simon? >>> It might explain some difficulties I have been experiencing. > >> Well, one bug that seems to recur frequently is mishandling of RENAMES, >> and not obscure renamings either, things like attribute renaming: >> Length : Natural renames Some_Array'Length; > > That's illegal, because Some_Array'Length denotes a value, > not an object, so you can't use it like that in an > object_renaming_declaration. GNAT correctly detects > this error. I don't see any mishandling here. > Am I missing something? Probably just that people are very confused about what one can rename. It's completely illogical, but as Bob says, it's a language issue and not (necessarily) a compiler issue. For instance: Next : Natural renames Natural'Pred(1); *is* legal, as Pred represents a function, and function results represent objects. Similarly, in Ada 2012: Ren1 : Natural renames Func(1); -- Legal. Ren2 : Natural renames Natural'(Func(1)); -- Legal. Ren3 : Natural renames Natural(Func(1)); -- Illegal!!! At least Ada 2020 will fix this one. But try this: Ren4 : Boolean renames Boolean'(A and B); -- Legal. Ren5 : Boolean renames Boolean'(A and then B); -- Illegal. Ren6 : Boolean renames "and"(A, B); -- Legal. Ren7 : Boolean renames A and B; -- Illegal. "and" is an operator function here, so it's an object and can be renamed. But "and then" is an operation and thus can't be renamed. Ren7 is illegal be infix notation is not a "name", so this renaming is illegal syntax. Note that every one of these renames was illegal in Ada 83. Someone thought that it was important to allow Ren1 in Ada 95, and that led to all of these bizarre cases. Anyone who claims they understand what can and cannot be renamed intuitively is a liar. :-) Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-31 22:51 ` Randy Brukardt @ 2018-09-01 19:42 ` Robert A Duff 2018-09-02 8:04 ` Dmitry A. Kazakov 2018-09-02 10:11 ` AdaMagica 1 sibling, 1 reply; 55+ messages in thread From: Robert A Duff @ 2018-09-01 19:42 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > Note that every one of these renames was illegal in Ada 83. Someone thought > that it was important to allow Ren1 in Ada 95, and that led to all of these > bizarre cases. I think it was mostly accidental. We needed to say that the result of a function call is an object (as opposed to a value, as in Ada 83), because it needs to get finalized. This caused renaming of function calls to become legal, which we viewed as harmless and sometimes useful. We didn't take the further step of making all the other cases you mentioned legal. Perhaps we should have, just for uniformity. - Bob ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-01 19:42 ` Robert A Duff @ 2018-09-02 8:04 ` Dmitry A. Kazakov 0 siblings, 0 replies; 55+ messages in thread From: Dmitry A. Kazakov @ 2018-09-02 8:04 UTC (permalink / raw) On 2018-09-01 21:42, Robert A Duff wrote: > "Randy Brukardt" <randy@rrsoftware.com> writes: > >> Note that every one of these renames was illegal in Ada 83. Someone thought >> that it was important to allow Ren1 in Ada 95, and that led to all of these >> bizarre cases. > > I think it was mostly accidental. We needed to say that the result of > a function call is an object (as opposed to a value, as in Ada 83), > because it needs to get finalized. This caused renaming of > function calls to become legal, which we viewed as harmless > and sometimes useful. I think distinction object vs. value is a wrong. Renaming should apply to named entities, e.g. *named* objects. Renaming anonymous things makes no sense, IMO. > We didn't take the further step of making all the other cases > you mentioned legal. Perhaps we should have, just for uniformity. Uniformly counterintuitive. If an expression to be named, that intuitively should have semantics of a call. E.g. Line : String renames Get_Line (File); begin loop Put_Line (Line); -- Dumping all the file end loop; exception when End_Error => -- From Put_Line, not from declaration! null; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-31 22:51 ` Randy Brukardt 2018-09-01 19:42 ` Robert A Duff @ 2018-09-02 10:11 ` AdaMagica 2018-09-02 12:10 ` Jeffrey R. Carter 1 sibling, 1 reply; 55+ messages in thread From: AdaMagica @ 2018-09-02 10:11 UTC (permalink / raw) Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt: > Similarly, in Ada 2012: > Ren1 : Natural renames Func(1); -- Legal. > Ren2 : Natural renames Natural'(Func(1)); -- Legal. > Ren3 : Natural renames Natural(Func(1)); -- Illegal!!! > > At least Ada 2020 will fix this one. But try this: > Ren4 : Boolean renames Boolean'(A and B); -- Legal. > Ren5 : Boolean renames Boolean'(A and then B); -- Illegal. > Ren6 : Boolean renames "and"(A, B); -- Legal. > Ren7 : Boolean renames A and B; -- Illegal. Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax. 3.3(2) defines objects. (BTW: Shouldn't the term object here be in italics?) Ren2 is a qualified expression with an object as operand. OK Ren3 is a type conversion of an object, which is a name. A type conversion is not an object. So Gnat is wrong? Ren4 and Ren5 both rename a qualified expression, but neither operand in an object. So Gnat is wrong again? > Anyone who claims they understand what can and cannot be renamed intuitively > is a liar. :-) True ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-02 10:11 ` AdaMagica @ 2018-09-02 12:10 ` Jeffrey R. Carter 2018-09-02 14:30 ` AdaMagica 0 siblings, 1 reply; 55+ messages in thread From: Jeffrey R. Carter @ 2018-09-02 12:10 UTC (permalink / raw) On 09/02/2018 12:11 PM, AdaMagica wrote: > Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt: >> Similarly, in Ada 2012: >> Ren1 : Natural renames Func(1); -- Legal. >> Ren2 : Natural renames Natural'(Func(1)); -- Legal. >> Ren3 : Natural renames Natural(Func(1)); -- Illegal!!! >> >> At least Ada 2020 will fix this one. But try this: >> Ren4 : Boolean renames Boolean'(A and B); -- Legal. >> Ren5 : Boolean renames Boolean'(A and then B); -- Illegal. >> Ren6 : Boolean renames "and"(A, B); -- Legal. >> Ren7 : Boolean renames A and B; -- Illegal. > > Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax. FSF GNAT 8.0.1 rejects all 3: $ gnatmake renaming.ads gcc-8 -c renaming.ads renaming.ads:9:27: renaming of conversion only allowed for tagged types renaming.ads:11:34: expect object name in renaming renaming.ads:13:28: missing ";" gnatmake: "renaming.ads" compilation error -- Jeff Carter "Blessed are they who convert their neighbors' oxen, for they shall inhibit their girth." Monty Python's Life of Brian 83 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-02 12:10 ` Jeffrey R. Carter @ 2018-09-02 14:30 ` AdaMagica 2018-09-04 22:05 ` Randy Brukardt 0 siblings, 1 reply; 55+ messages in thread From: AdaMagica @ 2018-09-02 14:30 UTC (permalink / raw) Am Sonntag, 2. September 2018 14:10:36 UTC+2 schrieb Jeffrey R. Carter: > On 09/02/2018 12:11 PM, AdaMagica wrote: > > Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt: > >> Similarly, in Ada 2012: > >> Ren1 : Natural renames Func(1); -- Legal. > >> Ren2 : Natural renames Natural'(Func(1)); -- Legal. > >> Ren3 : Natural renames Natural(Func(1)); -- Illegal!!! > >> > >> At least Ada 2020 will fix this one. But try this: > >> Ren4 : Boolean renames Boolean'(A and B); -- Legal. > >> Ren5 : Boolean renames Boolean'(A and then B); -- Illegal. > >> Ren6 : Boolean renames "and"(A, B); -- Legal. > >> Ren7 : Boolean renames A and B; -- Illegal. > > > > Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, which is an expression, and that cannot be renamed according to syntax. > > FSF GNAT 8.0.1 rejects all 3: > > $ gnatmake renaming.ads > gcc-8 -c renaming.ads > renaming.ads:9:27: renaming of conversion only allowed for tagged types > renaming.ads:11:34: expect object name in renaming I guess this is Ren5. Why should Ren4 be legal? Also "A and B" is an expression, not an object. "and"(A,B) is a function call, thus an object, whereas infix "and" in Ren4 is not a function call, but an expression. Ah, I found AARM 6.4(3.a/3). This makes Ren4 legal. So of course "and then" not being an operator, the expression in Ren5 is not considered a function call. Truly bizarre rules. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-02 14:30 ` AdaMagica @ 2018-09-04 22:05 ` Randy Brukardt 0 siblings, 0 replies; 55+ messages in thread From: Randy Brukardt @ 2018-09-04 22:05 UTC (permalink / raw) "AdaMagica" <christ-usch.grein@t-online.de> wrote in message news:9cfac5e5-5475-4219-96f1-970a47e91c28@googlegroups.com... > Am Sonntag, 2. September 2018 14:10:36 UTC+2 schrieb Jeffrey R. Carter: >> On 09/02/2018 12:11 PM, AdaMagica wrote: >> > Am Samstag, 1. September 2018 00:51:42 UTC+2 schrieb Randy Brukardt: >> >> Similarly, in Ada 2012: >> >> Ren1 : Natural renames Func(1); -- Legal. >> >> Ren2 : Natural renames Natural'(Func(1)); -- Legal. >> >> Ren3 : Natural renames Natural(Func(1)); -- Illegal!!! >> >> >> >> At least Ada 2020 will fix this one. But try this: >> >> Ren4 : Boolean renames Boolean'(A and B); -- Legal. >> >> Ren5 : Boolean renames Boolean'(A and then B); -- Illegal. >> >> Ren6 : Boolean renames "and"(A, B); -- Legal. >> >> Ren7 : Boolean renames A and B; -- Illegal. >> > >> > Ahem, perhaps my Gnat 2018 is not correct, but it rejects only Ren7, >> > which is an expression, and that cannot be renamed according to syntax. >> >> FSF GNAT 8.0.1 rejects all 3: >> >> $ gnatmake renaming.ads >> gcc-8 -c renaming.ads >> renaming.ads:9:27: renaming of conversion only allowed for tagged types >> renaming.ads:11:34: expect object name in renaming > I guess this is Ren5. > Why should Ren4 be legal? Also "A and B" is an expression, not an object. > "and"(A,B) is a function call, thus an object, whereas infix "and" in Ren4 > is not a function call, but an expression. > > Ah, I found AARM 6.4(3.a/3). This makes Ren4 legal. > So of course "and then" not being an operator, the expression in Ren5 is > not considered a function call. > > Truly bizarre rules. Yup. For what it's worth, I started investigating this when I was writing an ACATS test to check that "a qualified expression of an object is an object" and the inverse. So that ACATS test is relatively new and GNAT probaby was changed to do this exactly right at that time. (It's not the sort of case an implementer is likely to worry about absent a test). Randy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-27 16:54 ` Bill Findlay 2018-08-27 17:42 ` Shark8 @ 2018-09-01 7:41 ` Simon Wright 2018-09-01 17:27 ` Bill Findlay 1 sibling, 1 reply; 55+ messages in thread From: Simon Wright @ 2018-09-01 7:41 UTC (permalink / raw) Bill Findlay <findlaybill@blueyonder.co.uk> writes: > On 27 Aug 2018, Simon Wright wrote > (in article <lysh30kv4l.fsf@pushface.org>): >> There are also bugs in the front/back end interface, which can be >> triggered by unusual Ada usages. But, (a) unusual, (b) when found, >> fixed quickly (IME). >> >> And there are bugs in the backend; e.g. currently some problems with >> LTO/Darwin. > > Could you say more about that, Simon? > It might explain some difficulties I have been experiencing. Sorry for delayed response. It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 - Early lto debug not implemented on Darwin. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-09-01 7:41 ` Simon Wright @ 2018-09-01 17:27 ` Bill Findlay 0 siblings, 0 replies; 55+ messages in thread From: Bill Findlay @ 2018-09-01 17:27 UTC (permalink / raw) On 1 Sep 2018, Simon Wright wrote (in article <lywos5r7ek.fsf@pushface.org>): > Bill Findlay<findlaybill@blueyonder.co.uk> writes: > > > On 27 Aug 2018, Simon Wright wrote > > (in article<lysh30kv4l.fsf@pushface.org>): > > > > There are also bugs in the front/back end interface, which can be > > > triggered by unusual Ada usages. But, (a) unusual, (b) when found, > > > fixed quickly (IME). > > > > > > And there are bugs in the backend; e.g. currently some problems with > > > LTO/Darwin. > > > > Could you say more about that, Simon? > > It might explain some difficulties I have been experiencing. > > Sorry for delayed response. > > It's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 - Early lto > debug not implemented on Darwin. Thanks for that - it's not what I was experiencing. -- Bill Findlay ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 20:24 ` patrick 2018-08-25 21:48 ` Luke A. Guest @ 2018-08-27 17:35 ` Shark8 1 sibling, 0 replies; 55+ messages in thread From: Shark8 @ 2018-08-27 17:35 UTC (permalink / raw) On Saturday, August 25, 2018 at 2:24:28 PM UTC-6, pat...@spellingbeewinnars.org wrote: > > I am not sure what to do? > > I don't even know what the a4 project is that Luke spoke of and Byron has not had a commit in over a year and is a massive undertaking. I know it hasn't -- I've been a bit... depressed the past couple of years. That really takes a toll when there's only one person working the project. Things are looking up now, and I hope to get development restarted soon; though this likely will involve first typing up design documents and bringing the current codebase up to spec. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 19:25 ` Simon Wright 2018-08-25 20:24 ` patrick @ 2018-08-25 21:17 ` Luke A. Guest 2018-08-25 23:16 ` Paul Rubin 2 siblings, 0 replies; 55+ messages in thread From: Luke A. Guest @ 2018-08-25 21:17 UTC (permalink / raw) Simon Wright <simon@pushface.org> wrote: >> I know what trouble you have had with GCC and trying to get GNAT >> ported over to ARM many years ago. > > That was very frustrating. When others (including me) joined in with > more evidence things improved. That really pissed me off. They kept saying it worked for them. Well, they had complete sources which nobody else had, so, quel surprise?? This is a major issue in how things are done right now. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 19:25 ` Simon Wright 2018-08-25 20:24 ` patrick 2018-08-25 21:17 ` Luke A. Guest @ 2018-08-25 23:16 ` Paul Rubin 2018-08-26 8:03 ` Rene 2018-08-26 10:09 ` Simon Wright 2 siblings, 2 replies; 55+ messages in thread From: Paul Rubin @ 2018-08-25 23:16 UTC (permalink / raw) Simon Wright <simon@pushface.org> writes: > I'm far from expert on GCC procedures, but all three of the Ada > front-end maintainers (see [1]) are AdaCore employees, and I don't think > you're going to get approval for updates to Ada internals from anyone > else. Unless you've got some particular reason to believe that (e.g. based on experience submitting patches), I tend to be skeptical. Most FOSS projects love getting good patches (patches that work, are tested, conform to the project's standards and interfaces, etc.) What they don't like is "homework assignments", i.e. someone else coming along and telling them to do some work (unless they are a paying customer of course). I haven't been involved with GNAT at all, but I've contributed to GCC and have found the maintainers to generally be receptive to patches where the submitter is the one who does the work, and they're at least somewhat willing to advise about what work is needed. What they don't want is "please implement feature X" or even "here is my crappy patch, please clean it up, test it, rework it so it fits the rest of the codebase, etc., all for free". That's what support contracts are for. When it's a clean patch that really improves things and includes all necessary documentation and tests, it is usually smooth sailing. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 23:16 ` Paul Rubin @ 2018-08-26 8:03 ` Rene 2018-08-26 10:09 ` Simon Wright 1 sibling, 0 replies; 55+ messages in thread From: Rene @ 2018-08-26 8:03 UTC (permalink / raw) Am 26.08.2018 um 01:16 schrieb Paul Rubin: > Simon Wright <simon@pushface.org> writes: >> I'm far from expert on GCC procedures, but all three of the Ada >> front-end maintainers (see [1]) are AdaCore employees, and I don't think >> you're going to get approval for updates to Ada internals from anyone >> else. > > Unless you've got some particular reason to believe that (e.g. based on > experience submitting patches), I tend to be skeptical. Most FOSS > projects love getting good patches (patches that work, are tested, > conform to the project's standards and interfaces, etc.) What they > don't like is "homework assignments", i.e. someone else coming along and > telling them to do some work (unless they are a paying customer of > course). > I agree. The proposal sounds a bit like "Hey, I have a great idea what needs to be done but somebody has to do (most of) it." If you approach people like this you probably will hear the answer "I'm sorry, your idea may be great, but you have do it yourself because nobody will do it for you." ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 23:16 ` Paul Rubin 2018-08-26 8:03 ` Rene @ 2018-08-26 10:09 ` Simon Wright 1 sibling, 0 replies; 55+ messages in thread From: Simon Wright @ 2018-08-26 10:09 UTC (permalink / raw) Paul Rubin <no.email@nospam.invalid> writes: > Simon Wright <simon@pushface.org> writes: >> I'm far from expert on GCC procedures, but all three of the Ada >> front-end maintainers (see [1]) are AdaCore employees, and I don't >> think you're going to get approval for updates to Ada internals from >> anyone else. > > Unless you've got some particular reason to believe that (e.g. based > on experience submitting patches), I tend to be skeptical. Most FOSS > projects love getting good patches (patches that work, are tested, > conform to the project's standards and interfaces, etc.) What they > don't like is "homework assignments", i.e. someone else coming along > and telling them to do some work (unless they are a paying customer of > course). > > I haven't been involved with GNAT at all, but I've contributed to GCC > and have found the maintainers to generally be receptive to patches > where the submitter is the one who does the work, and they're at least > somewhat willing to advise about what work is needed. What they don't > want is "please implement feature X" or even "here is my crappy patch, > please clean it up, test it, rework it so it fits the rest of the > codebase, etc., all for free". That's what support contracts are for. > > When it's a clean patch that really improves things and includes all > necessary documentation and tests, it is usually smooth sailing. A patch that fixes a bootstrap-preventing ICE on Darwin is (a) likely not to be in the Ada internals even if it's in the Ada directories, (b) equally likely to be discussed/accepted by Darwin maintainers as by Ada maintainers. A small patch that fixed a wide character encoding problem was approved but the identical patch actually applied (some time later) was originated by an AdaCore employee. (I was miffed about this, you can tell) A patch that fixed an ICE was rejected because AdaCore had a better fix in mind for their own source tree (I can see there may well be fork-related issues here). Aside from the hairy nature of the compiler internals, this is my main reason for not trying to add features to the compiler: AdaCore have a development plan that we aren't party to, and almost any change could be affected. Also, I have quite enough to interest me anyway! ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 12:27 Studying and Maintaining GNAT, Is There Any Interest in a New Group? patrick 2018-08-25 13:56 ` Dan'l Miller 2018-08-25 16:16 ` Luke A. Guest @ 2018-08-25 16:43 ` Jeffrey R. Carter 2018-08-25 17:38 ` patrick 2 siblings, 1 reply; 55+ messages in thread From: Jeffrey R. Carter @ 2018-08-25 16:43 UTC (permalink / raw) On 08/25/2018 02:27 PM, patrick@spellingbeewinnars.org wrote: > > If I started a new group with the goal of discussing GNAT internals and maintaining GNAT it outside of Adacore, would anyone join? What would this group do that the FSF GNAT maintainers don't do? -- Jeff Carter "I snapped my chin down onto some guy's fist and hit another one in the knee with my nose." Play It Again, Sam 129 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 16:43 ` Jeffrey R. Carter @ 2018-08-25 17:38 ` patrick 2018-08-25 17:39 ` Luke A. Guest 0 siblings, 1 reply; 55+ messages in thread From: patrick @ 2018-08-25 17:38 UTC (permalink / raw) So correct me if I am wrong but the FSF people don't actually do anything with GNAT do they? I thought they were simply taking new revisions from Adacore after Adacore waits for a prolonged period. Is there anyone maintaining gnat outside of Adacore? Is there anyone that can take GNAT in a new direction? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 17:38 ` patrick @ 2018-08-25 17:39 ` Luke A. Guest 2018-08-25 17:45 ` patrick 0 siblings, 1 reply; 55+ messages in thread From: Luke A. Guest @ 2018-08-25 17:39 UTC (permalink / raw) <patrick@spellingbeewinnars.org> wrote: > > Is there anyone maintaining gnat outside of Adacore? Is there anyone that > can take GNAT in a new direction? > AFAIK there isn’t. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? 2018-08-25 17:39 ` Luke A. Guest @ 2018-08-25 17:45 ` patrick 0 siblings, 0 replies; 55+ messages in thread From: patrick @ 2018-08-25 17:45 UTC (permalink / raw) > AFAIK there isn’t. So this would mean that there is a purpose for the group, an alternative to Adacore which has pressure to pay bills and whatnot and may be taking the main free, open source Ada compiler in an unwanted direction. ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2018-09-04 22:18 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-25 12:27 Studying and Maintaining GNAT, Is There Any Interest in a New Group? patrick 2018-08-25 13:56 ` Dan'l Miller 2018-08-25 16:00 ` patrick 2018-08-25 16:16 ` Luke A. Guest 2018-08-25 17:42 ` patrick 2018-08-25 19:25 ` Simon Wright 2018-08-25 20:24 ` patrick 2018-08-25 21:48 ` Luke A. Guest 2018-08-25 21:53 ` patrick 2018-08-25 22:05 ` Luke A. Guest 2018-08-26 19:54 ` Dan'l Miller 2018-08-26 20:14 ` Dan'l Miller 2018-08-26 22:52 ` Lucretia 2018-08-27 2:38 ` Dan'l Miller 2018-08-27 14:46 ` Lucretia 2018-08-27 15:42 ` Dan'l Miller 2018-08-27 21:27 ` Randy Brukardt 2018-08-28 7:26 ` Dmitry A. Kazakov 2018-08-29 0:16 ` Randy Brukardt 2018-08-29 8:20 ` Dmitry A. Kazakov 2018-08-29 21:43 ` Randy Brukardt 2018-08-30 7:55 ` Dmitry A. Kazakov 2018-08-30 23:25 ` Randy Brukardt 2018-08-31 8:48 ` Dmitry A. Kazakov 2018-08-31 22:42 ` Randy Brukardt 2018-09-02 8:02 ` Dmitry A. Kazakov 2018-09-04 22:18 ` Randy Brukardt 2018-08-29 3:02 ` Paul Rubin 2018-08-29 6:18 ` Luke A. Guest 2018-08-29 19:00 ` Paul Rubin 2018-08-30 5:54 ` Luke A. Guest 2018-08-30 6:29 ` Paul Rubin 2018-08-27 21:18 ` Randy Brukardt 2018-08-27 9:37 ` Simon Wright 2018-08-27 16:54 ` Bill Findlay 2018-08-27 17:42 ` Shark8 2018-08-31 21:23 ` Robert A Duff 2018-08-31 22:51 ` Randy Brukardt 2018-09-01 19:42 ` Robert A Duff 2018-09-02 8:04 ` Dmitry A. Kazakov 2018-09-02 10:11 ` AdaMagica 2018-09-02 12:10 ` Jeffrey R. Carter 2018-09-02 14:30 ` AdaMagica 2018-09-04 22:05 ` Randy Brukardt 2018-09-01 7:41 ` Simon Wright 2018-09-01 17:27 ` Bill Findlay 2018-08-27 17:35 ` Shark8 2018-08-25 21:17 ` Luke A. Guest 2018-08-25 23:16 ` Paul Rubin 2018-08-26 8:03 ` Rene 2018-08-26 10:09 ` Simon Wright 2018-08-25 16:43 ` Jeffrey R. Carter 2018-08-25 17:38 ` patrick 2018-08-25 17:39 ` Luke A. Guest 2018-08-25 17:45 ` patrick
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox