From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Studying and Maintaining GNAT, Is There Any Interest in a New Group?
Date: Wed, 29 Aug 2018 16:43:22 -0500
Date: 2018-08-29T16:43:22-05:00 [thread overview]
Message-ID: <pm741r$9h8$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: pm5l0r$dek$1@gioia.aioe.org
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:pm5l0r$dek$1@gioia.aioe.org...
> On 2018-08-29 02:16, Randy Brukardt wrote:
>> "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.
>>>
>>> 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.
>
> Which makes the initial claim void. There is no nightmare and nothing to
> override what is not known in advance. For each "when" of the variant case
> there is an "override" in the inheritance scenario. If you know all
> "whens" you also know all "overrides".
Surely you "know" them; my point is that there is an incredible amount of
busy-work needed to write them (as opposed to just modifying the handful of
places that need that).
For instance, one has to write tree-walking code into every override, as
there is no good way to do that with inheritance (the override has to make a
dispatching call on itself on the child mode(s)). The only way to do that
with though inheritance is to move all of the tree-walking stuff outside of
the OO operations (as is done in the tree container) -- but then you are no
longer using strong typing on the children -- the number and kinds of the
children have to be checked with manual code.
>>> 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.
>
> That is the exact meaning of "in advance": before the final version of the
> program unit gets ready all variants must be known.
Umm, we're talking about a compiler, and there never is a "final" version of
a compiler. Unless it is dead where no one cares anymore. (That's true of
most decent-sized systems.) I might have a release version of Janus/Ad
today, but there will be another version next year and undoubtably that will
require node changes. (Indeed, it must, since I forgot to make qualified
expressions a "name" last time around. That means qualified expressions need
components for indexing and selection, and means shuffling variants about to
avoid duplication.)
>>> 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.
>
> Mostly yes, but the distributed overhead of maintenance is still there and
> it is no so safe as advertised. Consider the client code:
>
> if Current.Token = Integer_Token then
> -- Do something
> else
> -- Do something else
> end if;
>
> Here Integer_Token was used in the meaning "scalar". Later on somebody
> adds Float_Token and boom, it meant to be "scalar"!
Sure, but OO doesn't really help here: most properties aren't strictly
tree-like. For instance, many type categories don't follow inheritance rules
(limited being the obvious example).
> Even if replaced by case it is still could be unsafe if subtypes used:
>
> case Current.Token is
> when Scalar_Tokens => -- A subtype with Integer_Token in it
> when others =>
> end case;
>
> You must remember to make the subtype Scalar_Tokens covering the newly
> added Float_Token or else you get an intractable bug.
As noted before, use of "others" should be discouraged in case statements on
enumerations. That's an important item in our style guide; a bigger
organization probably would include it in their tool-based style checks.
If you had avoided "others", you'd get a compile-time error when Float_Token
was added. I take a lot of advantage of that Ada feature!
> Note that inheritance would handle this safely. It will be:
>
> Current.Token.Do_Something; -- A dispatching call override
>
> Do_Something would be abstract must-be-overridden for Float_Token.
Sure, but that's what's maddening about using OOP in this way. You have to
define and implement *every* such operation that way for a new node before
anything can be done (even compiling the changed program). There are likely
to be hundreds of such operations for a compiler (certainly dozens). That is
very much like monolithic waterfall development -- there is nothing agile
about it.
I try to keep the compiler compiled almost all of the time when doing
development, even when making major changes like new node kinds.
Compile-time errors tend to get eliminated first. That's in part because
code that isn't compilable shouldn't be checked in, and moreover we always
need to be able to make fixes for customers. The time while the compiler
isn't compilable is a risk period.
If instead you use some tool to make an empty set of TBDs for all of these
routines, now you've totally eliminated any compiler-based help (all of the
needed routines exist, they just don't *work*) and you have exactly the same
need for testing that you would have had using a variant. So you've gained
nothing.
>>> 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.
>
> It helps massively, especially interfaces, of course only when used
> properly during analysis and design phase in order to describe
> abstraction. One should use the strengths of typing instead of working
> around them. Variant records in place of interfaces is a path leading to
> weak typing. I don't say that one should never use variant records, I say
> that one should not misuse them.
I use strong typing to ensure that nodes don't get mixed with symbols or
with memory allocation record or many other things. I don't see any point in
treating nodes as different types. Spending a lot of extra time doing
analysis to try to bring structure where there is little natural structure
is wasteful at best.
And interfaces are only useful for true code reuse (across disparite
systems). Other than that, the percentage of times when you have more than
one instance of an interface approaches zero. In that case, an interface
only adds overhead and busy-work.
Randy.
next prev parent reply other threads:[~2018-08-29 21:43 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-25 12:27 Studying and Maintaining GNAT, Is There Any Interest in a New Group? patrick
2018-08-25 13:56 ` Dan'l Miller
2018-08-25 16:00 ` patrick
2018-08-25 16:16 ` Luke A. Guest
2018-08-25 17:42 ` patrick
2018-08-25 19:25 ` Simon Wright
2018-08-25 20:24 ` patrick
2018-08-25 21:48 ` Luke A. Guest
2018-08-25 21:53 ` patrick
2018-08-25 22:05 ` Luke A. Guest
2018-08-26 19:54 ` Dan'l Miller
2018-08-26 20:14 ` Dan'l Miller
2018-08-26 22:52 ` Lucretia
2018-08-27 2:38 ` Dan'l Miller
2018-08-27 14:46 ` Lucretia
2018-08-27 15:42 ` Dan'l Miller
2018-08-27 21:27 ` Randy Brukardt
2018-08-28 7:26 ` Dmitry A. Kazakov
2018-08-29 0:16 ` Randy Brukardt
2018-08-29 8:20 ` Dmitry A. Kazakov
2018-08-29 21:43 ` Randy Brukardt [this message]
2018-08-30 7:55 ` Dmitry A. Kazakov
2018-08-30 23:25 ` Randy Brukardt
2018-08-31 8:48 ` Dmitry A. Kazakov
2018-08-31 22:42 ` Randy Brukardt
2018-09-02 8:02 ` Dmitry A. Kazakov
2018-09-04 22:18 ` Randy Brukardt
2018-08-29 3:02 ` Paul Rubin
2018-08-29 6:18 ` Luke A. Guest
2018-08-29 19:00 ` Paul Rubin
2018-08-30 5:54 ` Luke A. Guest
2018-08-30 6:29 ` Paul Rubin
2018-08-27 21:18 ` Randy Brukardt
2018-08-27 9:37 ` Simon Wright
2018-08-27 16:54 ` Bill Findlay
2018-08-27 17:42 ` Shark8
2018-08-31 21:23 ` Robert A Duff
2018-08-31 22:51 ` Randy Brukardt
2018-09-01 19:42 ` Robert A Duff
2018-09-02 8:04 ` Dmitry A. Kazakov
2018-09-02 10:11 ` AdaMagica
2018-09-02 12:10 ` Jeffrey R. Carter
2018-09-02 14:30 ` AdaMagica
2018-09-04 22:05 ` Randy Brukardt
2018-09-01 7:41 ` Simon Wright
2018-09-01 17:27 ` Bill Findlay
2018-08-27 17:35 ` Shark8
2018-08-25 21:17 ` Luke A. Guest
2018-08-25 23:16 ` Paul Rubin
2018-08-26 8:03 ` Rene
2018-08-26 10:09 ` Simon Wright
2018-08-25 16:43 ` Jeffrey R. Carter
2018-08-25 17:38 ` patrick
2018-08-25 17:39 ` Luke A. Guest
2018-08-25 17:45 ` patrick
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox