Re: Why are Ada compilers difficult to write ?

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

On 2018-06-22 13:46, Dan'l Miller wrote:
> On Friday, June 22, 2018 at 12:01:37 AM UTC-5, J-P. Rosen wrote:
>> Le 21/06/2018 à 22:18, Dan'l Miller a écrit :
>>> Pascal, what makes freezing rules difficult when writing Ada compilers?
>>> 1) Is it that the freezing occurs later than what the compiler writer
>>> would find convenient, forcing the compiler writer to keep clay soft
>>> when it already seems to be in the kiln?> 2) Is it that freezing occurs prematurely, requiring the compiler
>>> writer to expend effort enforcing the freezing too early for no good
>>> reason?> 3) Is it that freezing rules are non-uniform/arbitrary/capricious
>>> across language constructs?> 4) Something else?
>>> 5) All of the above?
>>
>> I'm not Pascal ;-), but I'll answer these...
>> Please do not assume that language designers are masochists that make
>> the language unnecessarily complicated for no good reason. There are
>> good reasons, and these can usually be found in the annotated reference
>> manual.
> 
> I was merely trying to enumerate all the logically possible ways that freezing rules could make it harder on the compiler writer to which Pascal was referring.  Pascal is implying some sort of pain there.  I am trying to understand that pain more precisely than a terse “why?” would evoke.
> 
>> For example, if freezing happened at the end of a package (as you
>> suggest), it would not be possible to declare a variable or a constant
>> in the same package as its type (the type has to be frozen - i.e. its
>> representation determined - for an object to be declared). Therefore,
>> the declaration of an object freezes the type. Then, when you freeze a
>> type, of course you have to freeze all types of subcomponents. etc...
>> You end up with 13.14.
> 
> Well, in an alternate universe, there would be a way to accomplish those declarations of constants or variables in the same package as their subtypes.  In the alternate-universe Ada, Ada would have borrowed (on steroids in spades) the C++ idea of postponement/deferral of settling those affairs until the closing semicolon at the terminating end of the private section of the package.  A dependency graph would have naturally arisen among the various not-yet-frozen declarations.  If the dependency graph lacks a cycle of •conflicting• semantic requests among the declarations, then simply walk the dependency graph at the time of this later freezing, settling all requested affairs during  postponement/deferral roughly analogous to the way C++ later compiles member-function bodies during its class-closing-} postponement/deferral.

It is not a good idea IMO, regardless freezing rules. Ada's approach is 
"asymmetric", i.e. forward declarations or limited with declare certain 
aspects of the type or object limiting its use before full declaration.

An example why C++'s "symmetric" approach is not that good is this:

    type A is record
       Inner : B;
    end record;

    type B is record
       Inner : A;
    end record;

I bet outlining the rules necessary to handle such cases would take much 
longer than current freezing rules. And understanding them would be 
beyond normal programmer.

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