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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.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: Full view of a private partial view cannot be a subtype Date: Wed, 6 Dec 2017 18:52:13 -0600 Organization: JSA Research & Innovation Message-ID: References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> <43498b2a-773c-454a-b0e7-ade5d6594bd4@googlegroups.com> Injection-Date: Thu, 7 Dec 2017 00:52:12 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="21402"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:49399 Date: 2017-12-06T18:52:13-06:00 List-Id: >"Shark8" wrote in message >news:f73127a6-2334-430b-80a0-0ac9b9519e89@googlegroups.com... >On Tuesday, December 5, 2017 at 1:59:05 PM UTC-7, Randy Brukardt wrote: >> "Shark8" wrote in message >> news:43498b2a-773c-454a-b0e7-ade5d6594bd4googlegroups.com... >> ... >> >Besides UIs, the one problem that springs immediately to mind is the >> >internals of a >> >compiler's IR/parse-tree. >> >> I can speak to this (at least somewhat), and I think the full OOP version >> would be a nightmare. > >For [only] the Parse-tree/IR? >I honestly don't see why it wouldn't work as a hierarchy, and in fact think >it would naturally go that way, especially in an Ada program where you >have trees all over the place: the library-hierarchy, nesting of various >Ada-elements (package, subprogram, task), etc. Of course there is a hierarchy, but that is the least interesting feature of "full OOP" as I understand it. (Especially as a variant record is also a representation of a hierarchy.) A "full OOP" version has to use dispatching operations for essentially all operations on the parse-tree. But there are a *lot* of those operations. Just consider tree walks. Janus/Ada has five primary expression tree walks (remember, Janus/Ada doesn't use trees for anything bigger than an expression), and a number of secondary ones. These don't all walk the tree in the same way, given the different purposes. So one ends up with a whole bunch of primitive routines that walk the tree for different purposes and in slightly different ways. When you create a new kind of node (which should be fairly frequent for an agile programmers), you have to write bodies for all of these routines. A lot of the code of each routine is similar, but sharing that code is hard, given that it is interspresed with the other stuff that the tree walk is doing. For me (in the Claw Builder), it felt like implementing a lot of boilerplate. Then you have similar things for code generation, serialization (to read trees in and out), and so on. This sort of thing makes agile programming rather difficult (and I thought that big-bang programming was mostly dead), as one can't even compile (much less test) the new node until all of those routines exist somehow. That took a very long time investment for the Claw Builder, and I suspect a real compiler would be even worse. Worse, if you find you need a new kind of tree walk part way through development, you have to add a new kind of dispatching routine to the root of the tree, and then add implementations to every node type. That takes forever, and is absolutely not agile programming. Certainly, there are some tools that could help some, but my experience suggests that >Here's an interesting tutorial on Pratt Parsing that illustrates the >technique (albeit in >Java), but while it's on parsing in-general it shows how the elements >constructed >can be "smart" enough to construct themselves* This is no problem to do (as noted above), the problem is that the result is very hard to modify. And if you are building something large and long-lived like an Ada compiler, you WILL have to modify it a lot. Maybe Ada 2020 comes out, maybe you need to implement a new code generation technique (to improve performance or fix a problem with the existing one). Modifications of OOP designs are inside-out: what usually would be a local changes (say a special tree walk to be used in a generic instantiation case) tend to have to be done globally (a new dispatching routine has to be added to every node), and global changes (like adding a new node) tend to be more local. The problem with that is that adding a new node is rather rare (the Ada 2012 changes are the first new expression nodes in Janus/Ada since about 1990), while local fixes to fix bugs are rather common. You might be able to avoid this problem by abandoning OOP for significant parts of the code, but the OOP structure is not then gaining anything about extra work to write every dispatching routine. Someone who has never used variant records in Ada might not realize how strong a solution that they actually are to these sorts of problems, and thus might think that an OOP solution is the only way to go. But that's not really true. Randy.