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

["Randy Brukardt" <randy@rrsoftware.com>]

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