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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.10.203 with SMTP id 72mr17340088iok.8.1512513825240; Tue, 05 Dec 2017 14:43:45 -0800 (PST) X-Received: by 10.157.33.82 with SMTP id l18mr882434otd.6.1512513825136; Tue, 05 Dec 2017 14:43:45 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.kjsl.com!usenet.stanford.edu!i6no3868989itb.0!news-out.google.com!s63ni5172itb.0!nntp.google.com!193no2156904itr.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 5 Dec 2017 14:43:44 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=155.148.6.150; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 155.148.6.150 References: <889a3aed-4e6b-49c8-8c1c-6f1478e8e077@googlegroups.com> <43498b2a-773c-454a-b0e7-ade5d6594bd4@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Full view of a private partial view cannot be a subtype From: Shark8 Injection-Date: Tue, 05 Dec 2017 22:43:45 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:49394 Date: 2017-12-05T14:43:44-08:00 List-Id: On Tuesday, December 5, 2017 at 1:59:05 PM UTC-7, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:43498b2a-773c-454a-b0e7-ade5d6594bd4googlegroups.com... > ... > >Besides UIs, the one problem that springs immediately to mind is the=20 > >internals of a > >compiler's IR/parse-tree. >=20 > I can speak to this (at least somewhat), and I think the full OOP version= =20 > 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 hav= e trees all over the place: the library-hierarchy, nesting of various Ada-e= lements (package, subprogram, task), etc. Additionally, there are different extensions that could be made on a partic= ular 'node' -- say the formal generic parameters for a generic. Here's an interesting tutorial on Pratt Parsing that illustrates the techni= que (albeit in Java), but while it's on parsing in-general it shows how the= elements constructed can be "smart" enough to construct themselves* -- htt= p://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-= made-easy/=20 * Example: Type If_Conditional is new Node with record Test : Boolean_Expression; Branch : Statement_Sequence; end record --... =20 Type If_Else_Conditional is new If_Conditional with record Alternative : Statement_Sequence; end record --... >=20 > Janus/Ada (originally designed in the early 1980s, before there was such = a=20 > thing as type extension) uses variant records controlled by enumeration= =20 > discriminants. That is a very effective organization in Ada, because of t= wo=20 > features of Ada not found in most other languages - case completeness and= =20 > variant component checks. Variant-records are quite good, IMO. There's been several times where worki= ng in another OOP-language I've wished I could use Ada due to the case-comp= leteness and/or component-checks. (I view the component checks as merely a = special-case/-application of the completeness-checks; the coverage seems li= ke it ought to be "the same" [or at least generalizable like a sort].) >=20 > Thus, I'm unconvinced that a compiler data structure would be any advanta= ge=20 > written in OOP (at least, if the "conventional" version was written in Ad= a).=20 > I suspect the reason that OOP held some much advantage to many programmer= s=20 > (read, C programmers) is that they had a language which provided no help = at=20 > all for "conventional" programming, while Ada already had information=20 > hiding, true privacy, case completeness, variant component checks, array= =20 > index checks, etc. So the increment is so much less. >=20 > I think the only place OOP really holds an advantage is for programs base= d=20 > around call-backs (like most GUIs). And I think you'd be nuts to use=20 > call-backs if you don't have to, so there isn't much need for OOP (assumi= ng=20 > it is compared to "conventional" Ada and some some other language that le= ts=20 > one do anything, no matter how unintended). The above example does make use of the "use a classwide object to get aroun= d passing a subprogram" trick that was mentioned here on C.L.A a few years = back -- http://computer-programming-forum.com/44-ada/30caa21641c1ed2d.htm