Re: Full view of a private partial view cannot be a subtype

[Shark8 <onewingedshark@gmail.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.

Additionally, there are different extensions that could be made on a particular 'node' -- say the formal generic parameters for a generic.

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* -- http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/ 

* Example:
   Type If_Conditional is new Node with record
    Test   : Boolean_Expression;
    Branch : Statement_Sequence;
   end record
    --...
  
   Type If_Else_Conditional is new If_Conditional with record
     Alternative : Statement_Sequence;
   end record
   --...

> 
> Janus/Ada (originally designed in the early 1980s, before there was such a 
> thing as type extension) uses variant records controlled by enumeration 
> discriminants. That is a very effective organization in Ada, because of two 
> features of Ada not found in most other languages - case completeness and 
> variant component checks.

Variant-records are quite good, IMO. There's been several times where working in another OOP-language I've wished I could use Ada due to the case-completeness and/or component-checks. (I view the component checks as merely a special-case/-application of the completeness-checks; the coverage seems like it ought to be "the same" [or at least generalizable like a sort].)

> 
> Thus, I'm unconvinced that a compiler data structure would be any advantage 
> written in OOP (at least, if the "conventional" version was written in Ada). 
> I suspect the reason that OOP held some much advantage to many programmers 
> (read, C programmers) is that they had a language which provided no help at 
> all for "conventional" programming, while Ada already had information 
> hiding, true privacy, case completeness, variant component checks, array 
> index checks, etc. So the increment is so much less.
> 
> I think the only place OOP really holds an advantage is for programs based 
> around call-backs (like most GUIs). And I think you'd be nuts to use 
> call-backs if you don't have to, so there isn't much need for OOP (assuming 
> it is compared to "conventional" Ada and some some other language that lets 
> one do anything, no matter how unintended).

The above example does make use of the "use a classwide object to get around 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