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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-09-01 00:42, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:pmavco$u5d$1@gioia.aioe.org...
>> On 2018-08-31 01:25, Randy Brukardt wrote:
>>
>> Why isn't Fold class-wide:
>>
>>     procedure Fold (Expr : in out Binop'Class) is
>>     begin
>>        Fold (Expr.Left.all);
>>        Fold (Expr.Right.all);
>>        Expr.Evaluate; -- This dispatches to the Op's implementation
>>     end Fold;
> 
> There's not one "evaluate" operation here; there are 6 different phases of
> tree operations (construction, lookup, resolution, checking, folding, and
> conversion to low-level IR).

For each of them I would decide if that is a primitive or class-wide 
operation.

>> BTW, I prefer to fold constants before generating the tree. I.e. when
>> Evaluate is called it returns either a value ("constant" node) or a new
>> "dynamic" node.
> 
> In Ada, you can't do folding until you know what the operations are, and you
> don't know that until after resolution (that is, "*" could be predefined,
> which you can fold, or user-defined, which you probably can't fold, and
> certainly can't treat as static).

I meant folding universal constants. During/after type resolution one 
could generate the next tree and fold resolved constants then.

>>>>> Umm, we're talking about a compiler, and there never is a "final"
>>>>> version of a compiler.
>>>>
>>>> Final = deployed, of course.
>>>
>>> Which is relevant how? It's just a snapshot of a continual evolution.
>>
>> Each new release is another program. You might kill the whole package next
>> time, the code is not stable. With OO I can have stable pieces of code
>> frozen in separate packages which never change and keep adding volatile
>> code without rewriting everything each time.
> 
> Which again is relevant how?

To the meaning of "knowing in advance". You basically say that you do 
not know anything because the program gets sometimes changed.

> You might not have to change some code
> depending on the code structure, but the number of changes really only
> matter in true spaggetti code (where everything is everywhere). Expression
> tree manipulations are only a small part of the compiler (less than 25%,  I
> think). You could make it more by putting statements and declarations into
> those trees, but that wouldn't buy much and wouldn't add that much code to
> the tree manipulations, either. A lot of the code is handling the
> environment (with clauses and the like) as well as symbol table operations.

OK, that is basically this: it is not so much code, I can do it 
quick-and-dirty without much consideration. It is a valid argument in 
your case because you write and maintain this code all your life and 
could possibly do it while sleeping. (:-)) But as a general advice it is 
IMO wrong.

> I do too, but probably for the opposite reason: it's a fragile mechanism
> tied to a null extension. If you try to program agily, you might very well
> write the extension first and add the components later. Now you've suddenly
> got to override a bunch functions that were fine before -- which defeats the
> purpose of declaring the type first in the first place.

I ask what is agile here? The type with null extension is same. The 
operations are same. What was changed? Looks like useless and mindless 
activity to me.

> This problem is also a substantial one when using generic mix-ins, since the
> mix-in doesn't know about the functions in question and can't really do so.
> IMHO, it should work any time all of the components in the extension have
> well-defined defaults. Then the mix-in case would work with sufficient care,
> and if you want to force redefinition of everything, just have a component
> with no default.

Mix-in is never safe, should be replaced by MI and/or parallel type 
hierarchy mechanics.

> I have a different vision of static verification than you do; I'm primarily
> focused on static verification of Ada's dynamic checks. (Since that includes
> pragma Assert and the like, you can verify almost everything this way.)

It is OK, but low-level. One cannot organize such checks in a way of 
type checks,  which have inheritance, parameter matching, composition of 
new types. You lose a lot. Not everything can be checked by types, of 
course.

> And
> I want the compiler to do that - not the least because I would like to show
> that there are other possible visions for Ada compilers than AdaCore's. (And
> if it gets people to buy more compilers from me, all the better. :-)

It would be great to have a viable alternative to GNAT.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de