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 X-Received: by 2002:a24:3f4c:: with SMTP id d73-v6mr627457ita.30.1529670928427; Fri, 22 Jun 2018 05:35:28 -0700 (PDT) X-Received: by 2002:aca:d448:: with SMTP id l69-v6mr90523oig.0.1529670928226; Fri, 22 Jun 2018 05:35:28 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!u78-v6no688672itb.0!news-out.google.com!z3-v6ni839iti.0!nntp.google.com!d7-v6no693872itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 22 Jun 2018 05:35:27 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.195.62; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.195.62 References: <584564c2-9f64-4965-b045-535cdaf899c0@googlegroups.com> <2d287ba3-209d-4d6a-af79-77177a137885@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <07b437ae-80fd-452c-a3f5-768e233eb25c@googlegroups.com> Subject: Re: Why are Ada compilers difficult to write ? From: "Dan'l Miller" Injection-Date: Fri, 22 Jun 2018 12:35:28 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:53249 Date: 2018-06-22T05:35:27-07:00 List-Id: On Friday, June 22, 2018 at 7:11:28 AM UTC-5, Dmitry A. Kazakov wrote: > 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 =C3=A0 22:18, Dan'l Miller a =C3=A9crit=C2=A0: > >>> Pascal, what makes freezing rules difficult when writing Ada compiler= s? > >>> 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 occu= rs 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/capri= cious > >>> 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 referenc= e > >> manual. > >=20 > > I was merely trying to enumerate all the logically possible ways that f= reezing rules could make it harder on the compiler writer to which Pascal w= as referring. Pascal is implying some sort of pain there. I am trying to = understand that pain more precisely than a terse =E2=80=9Cwhy?=E2=80=9D wou= ld evoke. > >=20 > >> 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. > >=20 > > Well, in an alternate universe, there would be a way to accomplish thos= e declarations of constants or variables in the same package as their subty= pes. In the alternate-universe Ada, Ada would have borrowed (on steroids i= n spades) the C++ idea of postponement/deferral of settling those affairs u= ntil the closing semicolon at the terminating end of the private section of= the package. A dependency graph would have naturally arisen among the var= ious not-yet-frozen declarations. If the dependency graph lacks a cycle of= =E2=80=A2conflicting=E2=80=A2 semantic requests among the declarations, th= en simply walk the dependency graph at the time of this later freezing, set= tling all requested affairs during postponement/deferral roughly analogous= to the way C++ later compiles member-function bodies during its class-clos= ing-} postponement/deferral. >=20 > It is not a good idea IMO, regardless freezing rules. Ada's approach is= =20 > "asymmetric", i.e. forward declarations or limited with declare certain= =20 > aspects of the type or object limiting its use before full declaration. >=20 > An example why C++'s "symmetric" approach is not that good is this: >=20 > type A is record > Inner : B; > end record; >=20 > type B is record > Inner : A; > end record; 1) This red herring is not permitted in the analogous C++ syntax (because n= either A nor B is a postponed-/deferred-compilation =E2=80=A2=E2=80=A2body = of member-function=E2=80=A2=E2=80=A2). Even if you were to forward declare= B, that does not rectify the lack of body of member-function whose compila= tion gets deferred/postponed. 2) This red herring would not be permitted in the alternate-universe Ada (w= ith freezing at the ; of the not-shown terminating end of the package) due = to having the overtly prohibited =E2=80=A2cycle=E2=80=A2 of =E2=80=A2confli= cting=E2=80=A2 semantic requests (i.e., 2 infinite-length record).