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:4314:: with SMTP id s20-v6mr555686itb.4.1529668007916; Fri, 22 Jun 2018 04:46:47 -0700 (PDT) X-Received: by 2002:aca:abc6:: with SMTP id u189-v6mr80468oie.2.1529668007672; Fri, 22 Jun 2018 04:46:47 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!takemy.news.telefonica.de!telefonica.de!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!85.12.16.70.MISMATCH!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!d7-v6no656741itj.0!news-out.google.com!z3-v6ni731iti.0!nntp.google.com!d7-v6no656736itj.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 22 Jun 2018 04:46:47 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2d287ba3-209d-4d6a-af79-77177a137885@googlegroups.com> Subject: Re: Why are Ada compilers difficult to write ? From: "Dan'l Miller" Injection-Date: Fri, 22 Jun 2018 11:46:47 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5363 X-Received-Body-CRC: 1782239539 Xref: reader02.eternal-september.org comp.lang.ada:53246 Date: 2018-06-22T04:46:47-07:00 List-Id: 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 compilers?= =20 > > 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/caprici= ous > > across language constructs?> 4) Something else? > > 5) All of the above? >=20 > 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 freez= ing rules could make it harder on the compiler writer to which Pascal was r= eferring. Pascal is implying some sort of pain there. I am trying to unde= rstand that pain more precisely than a terse =E2=80=9Cwhy?=E2=80=9D would e= voke. > 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 de= clarations of constants or variables in the same package as their subtypes.= In the alternate-universe Ada, Ada would have borrowed (on steroids in sp= ades) 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 =E2= =80=A2conflicting=E2=80=A2 semantic requests among the declarations, then s= imply walk the dependency graph at the time of this later freezing, settlin= g all requested affairs during postponement/deferral roughly analogous to = the way C++ later compiles member-function bodies during its class-closing-= } postponement/deferral. =20 (I am not saying that that postponement/deferral would certainly be easier = for compiler writers than the existing freezing rules that Pascal is consid= ering a challenge for Ada compiler writers; I am merely exploring what pain= Pascal could have referring to. Also, I am well aware that Ada83's predec= essor of freezing rules predate C++'s postponement/deferral of compiling me= mber-function bodies that appear in the class declaration by somewhere on t= owards a decade, so Ada83 would have needed a time machine to borrow a page= from C++'s book there. That is why this all occurred in the alternate uni= verse, where perhaps alternate universe's Ada9X program would have had a re= quirement to lovingly embrace C++'s postponement/deferral as part & parcel = of Ada9X's retort to the rise of C++, where alternate-universe's Ada9X AJPO= requirements would have overtly rejected Ada83's precursor of freezing rul= es instead of our timeline's AJPO's tacit permission to expand them.) Conversely, to OP's question: C++ (as the modern C replacement) freezes al= l types at the point of nonforward declaration, without any later adjustmen= ts to size or layout. That is simpler than Ada's let-it-float-for-just-awh= ile freezing rules.