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.176.83.133 with SMTP id k5mr13846106uaa.23.1480555317789; Wed, 30 Nov 2016 17:21:57 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr2251844ote.8.1480555317750; Wed, 30 Nov 2016 17:21:57 -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!p16no573782qta.1!news-out.google.com!j8ni1940qtc.0!nntp.google.com!n6no574978qtd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 30 Nov 2016 17:21:57 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=174.28.218.229; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 174.28.218.229 References: <8b3ea401-822b-4b51-be48-133861ef2e0b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5eb00dbc-d36e-47e5-bc76-0d0683281c09@googlegroups.com> Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Thu, 01 Dec 2016 01:21:57 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32541 Date: 2016-11-30T17:21:57-08:00 List-Id: On Wednesday, November 30, 2016 at 3:17:51 PM UTC-7, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:8b3ea401-822b-4b51-be48-133861ef2e0b... > >On Tuesday, November 29, 2016 at 4:52:20 PM UTC-7, Randy Brukardt wrote: > >> > >> P0 and P1 are more likely to be optimized by a compiler (just because = of=20 > >> the > >> many years of history). Perhaps P3 will catch up, but I wouldn't hold = my > >> breath on that. > > > >Oh, BTW, *THIS* is exactly the motivation for having a uniform IR -- whe= n=20 > >put into a > >common form then all optimizations on that object/construct are applicab= le.=20 > >This is to > >say that when P3 and P1 share a representation, every optimization of P1= is=20 > >possible > >for P3. (Despite syntax differences; again, assuming they're truly=20 > >equivalent in the same > >way that "Integer > 0" and "Integer in 1..Integer'Last" are.) >=20 > We don't do any optimizations in the high-level IR (that would be express= ion=20 > trees); that's all done in the conversion to the low-level IR (the stack= =20 > based machine) or on that IR directly. There's few Ada constructs in the= =20 > low-level IR. Hm, I think I see your point. > In any case, the semantic description of the two constructs is different,= =20 > although as far as I know the effect is the same. My experience in Ada is= =20 > that whenever you think you can collapse Ada constructs, you eventually w= ill=20 > be proved wrong, either by a new ACATS test, a customer bug report, or by= =20 > some future change in the language (either a bug fix or new revision). I= =20 > would generally reecommend avoiding that as much as possible. Then maybe this is a valid issue to put in an Ada-comment; the thinking of = things in terms of sets is something that's been in Ada since its inception= (eg case-coverage) -- and acknowledging that the common definition of 'typ= e' as "a set of values and a set of operations on those values" is solid en= ough that codifying those constructs as the same would be useful to impleme= ntations, no?