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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group? Date: Tue, 28 Aug 2018 19:16:19 -0500 Organization: JSA Research & Innovation 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> Injection-Date: Wed, 29 Aug 2018 00:16:22 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="10520"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:54286 Date: 2018-08-28T19:16:19-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:pm2tfi$1sv1$1@gioia.aioe.org... > On 2018-08-27 23:27, Randy Brukardt wrote: >> "Lucretia" 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.