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.99.45.68 with SMTP id t65mr14304229pgt.151.1480469061907; Tue, 29 Nov 2016 17:24:21 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr1467233ote.8.1480469061826; Tue, 29 Nov 2016 17:24:21 -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.fcku.it!peer02.fr7!futter-mich.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!p16no64773qta.1!news-out.google.com!j8ni250qtc.0!nntp.google.com!p16no64769qta.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 29 Nov 2016 17:24:21 -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: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <638d0618-f565-47ef-9793-dd05a4b1a662@googlegroups.com> Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Wed, 30 Nov 2016 01:24:21 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 1255448358 X-Received-Bytes: 4483 Xref: news.eternal-september.org comp.lang.ada:32528 Date: 2016-11-29T17:24:21-08:00 List-Id: On Tuesday, November 29, 2016 at 4:52:20 PM UTC-7, Randy Brukardt wrote: > "Shark8" wrote in message=20 > news:c06ee4e6-d616-4e01-ba2e-cb111a81f6f6@... > >So, with Ada 2012 we gained some really nice possibilities with the way = to=20 > >express constraints, the > >downside is that there's now a fairly wide range of ways to express=20 > >constraints on types. Obviously > >these differences must be accounted for, but the are functionally=20 > >equivalent, for example: > > > >Subtype P0 is Natural range Natural'Succ(Natural'First)..Natural'Last; > >Subtype P1 is Integer range 1..Integer'Last; > >Subtype P2 is Integer with Static_Predicate =3D> P2 in 1..Integer'Last o= r=20 > >else raise Constraint_Error; > >Subtype P3 is Integer with > > Static_Predicate =3D> P3 in 1..Integer'Last, > > Predicate_Failure =3D> raise Constraint_Error; > > > >Now, these should be generally the same way of writing the same thing (i= e=20 > >"Positive") -- though > > I'm not completely certain that this is the case in terms of subtle=20 > > semantics (am I missing something?) >=20 > P2 is different than the others when used in a membership: >=20 > Obj in P2 >=20 > would raise Constraint_Error rather than return False (like the others) i= f=20 > Obj has the value 0. It's not recommended. Ah, I didn't realize that... I see the logic of why it does that: it fails = the predicate's membership-test and then executes the raise-statement. But = if that's the case whey isn't P3 the same? It is, after all, failing the me= mbership-test and therefore failing the predicate, no? > P0 and P1 are more likely to be optimized by a compiler (just because of = the=20 > many years of history). Perhaps P3 will catch up, but I wouldn't hold my= =20 > breath on that. What I'm saying is that P0, P1, and P3 (and perhaps arguably P2) should be = represented as the same thing... that there ought to be some way to abstrac= t types and subtypes so that there is a common representation. Just like a function with a single simple return-statement and an expressio= n-function should be able to be represented as the same thing because the s= tandard says the forms are equivalent. eg: Function One return Integer is begin return 1; end One; and Function One return Integer is (1); Could be represented by a parse-tree construct that looks something like th= is: Function_node name : one parameters : () return_type: Integer body : Value_node Type : integer Value: 1 ^ L__ Deliberately not Ada-syntax. Maybe with a field for keeping track of whether or not an expression-functi= on or long-form function are being used... or that could be discarded and l= et the programmer's viewer-tool take care of how it should display it. The point is that we can have the IR capable of representing the construct = "function" uniformly despite syntax-permutations -- Since types are, as not= ed upthread, a set of values and a set of operations on those values, there= ought to be a way to represent a type in a uniform manner, right?