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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.157.34.52 with SMTP id o49mr64706ota.106.1483585460796; Wed, 04 Jan 2017 19:04:20 -0800 (PST) X-Received: by 10.157.31.20 with SMTP id x20mr3479799otd.10.1483585460719; Wed, 04 Jan 2017 19:04:20 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!b123no401981itb.0!news-out.google.com!u18ni6248ita.0!nntp.google.com!b123no404126itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 4 Jan 2017 19:04:20 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=67.0.242.189; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 67.0.242.189 References: <87r34j39u6.fsf@nightsong.com> <7643d59e-061f-42df-adda-9322608f127b@googlegroups.com> <75f2482a-a94b-4820-b2b1-990010103709@googlegroups.com> <4c5dfbe4-7987-48d4-8afc-817a8c134095@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <41be5cb7-dc93-4a4c-a92d-83b31949fd15@googlegroups.com> Subject: Re: Introductory Ada Programming Book From: Shark8 Injection-Date: Thu, 05 Jan 2017 03:04:20 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:33062 Date: 2017-01-04T19:04:20-08:00 List-Id: On Wednesday, January 4, 2017 at 2:47:05 PM UTC-7, Randy Brukardt wrote: > "Shark8" wrote in message=20 > > On Wednesday, January 4, 2017 at 6:45:29 AM UTC-7, raph....@gmail.com wro= te: > > Le mercredi 4 janvier 2017 13:49:18 UTC+1, Dmitry A. Kazakov a =C3=A9cr= it : > >> > > >> > declare > >> > I : Integer :=3D 1; -- OK > >> > J : Integer; -- Error: not initialized > >> > K : Integer :=3D <>; -- OK: uninitialized, I know what I am doin= g > >> > > >> > >> Or do it Swift's way and use flow analysis to make use of an=20 > >> uninitialized variable > >> a compile time error. Meh. I guess it's complicated enough as it is to= =20 > >> implement > >> an Ada compiler :) > > > >Well, there are certain times where you *want*/*need* non-initialized=20 > >variables; > > it's usually at [operating] system-level, but it does exist. (A good=20 > > example would > > me memory-mapped I/O ports, where your 'initialization' would=20 > > automatically > > send something down the I/O port when you might need to send nothing.) >=20 > Right. It also might happen if the initialization is very complex and=20 > interrelated with initializing other variables. Forcing an initialization= =20 > just to make the compiler happy would be confusing and potentially expens= ive=20 > (if the item is large). >=20 > I agree with Dmitry. Indeed, I tried hard in Ada 2005 to get (<>) to be a= n=20 > aggregate usable to default initialize for any type, with the intent to= =20 > combine that with a restriction to essentially allow projects to change A= da=20 > to the rule Dmitry suggested. Unfortunately, various technical issues wit= h=20 > private types made that much harder than originally thought, and the idea= =20 > was dropped late in the Ada 2005 work. >=20 > The problem with requiring flow analysis in a language rule is that it=20 > requires lengthy specifications of exactly what flow analysis is required= =20 > for this check, assuming that portability between implementations is=20 > important (and that surely is for Ada). Every compiler does some flow=20 > analysis, but each it likely to do it differently, in different compiler= =20 > phases, and having program legality be implementation-defined in that way= is=20 > a guaranteed way to have code that cannot be moved to a different=20 > implementation. (Exception contracts have a similar problem.) >=20 > Randy. Thank you for the explanation/info -- it's really good. (I hope we *can* get exception contracts.)