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.98.158.82 with SMTP id s79mr394291pfd.4.1481812462906; Thu, 15 Dec 2016 06:34:22 -0800 (PST) X-Received: by 10.157.17.167 with SMTP id v36mr127110otf.12.1481812462861; Thu, 15 Dec 2016 06:34:22 -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!b123no380790itb.0!news-out.google.com!c1ni8254itd.0!nntp.google.com!b123no380779itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 15 Dec 2016 06:34:22 -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: <5cc38920-b746-48f6-87d4-1cf8effa2f02@googlegroups.com> Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Thu, 15 Dec 2016 14:34:22 +0000 Content-Type: text/plain; charset=UTF-8 Xref: news.eternal-september.org comp.lang.ada:32849 Date: 2016-12-15T06:34:22-08:00 List-Id: On Thursday, December 15, 2016 at 1:41:50 AM UTC-7, Dmitry A. Kazakov wrote: > > I am against that, see above, it must be an integral part of the Ada's > declarative framework, never a module or a tool. Tooling is *the* most cited thing on my survey of why Ada isn't more popular -- it includes things like IDEs, too -- but you're conveniently ignoring almost everything I said because I mentioned C's Lint and how it wasn't used. > > Integrating these useful technologies into the compiler in a manner > > that is invisible to users [non-implementer Ada programmers] is a good > > way to ensure 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.]) > > Right, because it is a tool you could use or not. In Ada type > declarations must be there, so it is not a tool, but an integral part of > the language. This is why "pre"-aspects is a non-starter even ignoring > their semantic consistency issues. You can do things with or without > them. Psychologically it won't work. See? Right there, read my first sentence in that paragraph again. Here, I'll even quote it for you: > Integrating these useful technologies into the compiler in a manner that > is invisible to users [non-implementer Ada programmers] is a good way to > ensure that the tools are used. > > 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 values and a set of operations acting on those values. > > -- This maps directly to Ada, given the LRM's definition of subtypes. > > Well, but first it is an implementation issue, as such, of a very > secondary order to the question of constrained types and other means to > create new types. It seems like something's being lost in translation. Let me try restating it: * The thread asks about implementation of a particular concept. * The topic of the thread is of the implementation of a concept similar to the paper's. * The question posed at the start of this thread is about how to deal with representing the quality of Ada's subtypes as "a possibly empty set of constraints on a value". * Ada now has two syntactic methods of adding constraints to subtypes, the topic of the thread is how to represent these in a uniform manner. * The post is about how there ought to be a representation of the removal of values from a type which is suitable for all methods of expressing that concept in Ada. > Secondly arbitrary constraints is low level and thus a bad idea to > introduce into the type system, as dynamic predicates promptly > illustrate. Resemblance to Ada 83 subtypes is only superficial. No, it's not superficial. Here's why: I'm using the actual definitions of the LRM; it is quite clear that predicates on subtypes do the same basic function that range-constraints do: eliminating possible values from the parent-type's set of possible values.