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.36.55.5 with SMTP id r5mr1905510itr.27.1481751961308; Wed, 14 Dec 2016 13:46:01 -0800 (PST) X-Received: by 10.157.39.129 with SMTP id c1mr7063513otb.15.1481751961274; Wed, 14 Dec 2016 13:46:01 -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!75no168217ite.0!news-out.google.com!u18ni4665ita.0!nntp.google.com!b123no169043itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 14 Dec 2016 13:46:00 -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: <999c67b0-4478-4d2b-8108-32ac48fe6316@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Wed, 14 Dec 2016 21:46:01 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32832 Date: 2016-12-14T13:46:00-08:00 List-Id: On Wednesday, December 14, 2016 at 1:04:53 PM UTC-7, Dmitry A. Kazakov wrot= e: > On 2016-12-14 20:23, Shark8 wrote: > > Read this -- > > https://www.cs.unm.edu/~forrest/publications/negsharingilcp.pdf -- it's > > intuitively obvious how this is a possible answer to my original > > posting; it's also obvious how it can be used in solvers, since that's > > the particular domain the paper's about. >=20 > I don't see how is it relevant. Perhaps re-reading the first post would help: On Monday, November 28, 2016 at 4:49:39 PM UTC-7, Shark8 wrote: > So, with Ada 2012 we gained some really nice possibilities with the way t= o express constraints, the downside is that there's now a fairly wide range= of ways to express constraints on types. Obviously these differences must = be accounted for, but the are functionally equivalent, for example: >=20 > 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 or= else raise Constraint_Error; > Subtype P3 is Integer with > Static_Predicate =3D> P3 in 1..Integer'Last, > Predicate_Failure =3D> raise Constraint_Error; >=20 > Now, these should be generally the same way of writing the same thing (ie= "Positive") -- though I'm not completely certain that this is the case in = terms of subtle semantics (am I missing something?) -- it certainly would b= e convenient if they were as then we could have an IR wherein the general f= orm of a type-constraint is uniformly handled. >=20 > Comments? Insights? It's relevant because it is exactly showing how to represent restrictions [= exclusions] on values (within a set); and, as we know, a type is a set of v= alues and a set of operations acting on those values. -- This maps directly= to Ada, given the LRM's definition of subtypes. > > In this light, integrating SPARK proving with the Ada compiler could > > allow for better optimizations... and if it can be done in such a way > > that it can be leveraged in other portions of the compiler (say semanti= c > > checks), then why not use it? >=20 > When that comes into life, programmers surely will, though not in the=20 > form of preconditions, because as I said, it is bad design. The rule is= =20 > weakening preconditions, strengthening post-conditions. I think you may be overestimating the group "programmers". Seriously, the thread "C# new features (v.7)" -- https://groups.google.com/= forum/#!topic/comp.lang.ada/mLZIo_Sjm5c -- lists things that "modern" langu= ages are just getting that Ada has had for years. Integrating these useful technologies into the compiler in a manner that is= invisible to users [non-implementer Ada programmers] is a good way to ensu= re that the tools are used. (e.g. the Ada compiler does automatically what = C's Lint did, and is much better for it. [Most of the C programmers I knew = in college *never* used lint.]) Now, if we can also leverage these technologies to make implementations [of= Ada] better [quality-wise] and more maintainable, then that's win-win all = the way around at the cost of (a) designing your IR to be amiable to the pr= over-module, and (b) implementing the prover-module. And if you're doing a SPARK implementation then you'd need to do all the wo= rk for (b) anyway -- so in that case it's really at the cost of designing t= he IR... which, if you'll remember, is the real topic of this thread.