Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pm2tfi$1sv1$1@gioia.aioe.org...
> On 2018-08-27 23:27, Randy Brukardt wrote:
>> "Lucretia" <laguest9000@googlemail.com> 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.