From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? Date: Sun, 2 Sep 2018 10:02:19 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <309225242.556906218.575482.laguest-archeia.com@nntp.aioe.org> <2145221813.556924687.162377.laguest-archeia.com@nntp.aioe.org> <3892c779-2924-405c-b88d-19389fc5ba3e@googlegroups.com> <1ceec6d8-c5c4-49b1-9808-a3580bba3f8e@googlegroups.com> NNTP-Posting-Host: IzvqdhUtDGKIMCldyDtZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 X-Mozilla-News-Host: news://news.aioe.org X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:54309 Date: 2018-09-02T10:02:19+02:00 List-Id: On 2018-09-01 00:42, Randy Brukardt wrote: > "Dmitry A. Kazakov" 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