From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Why are Ada compilers difficult to write ? Date: Fri, 22 Jun 2018 14:11:25 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <584564c2-9f64-4965-b045-535cdaf899c0@googlegroups.com> <2d287ba3-209d-4d6a-af79-77177a137885@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:53248 Date: 2018-06-22T14:11:25+02:00 List-Id: 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