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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Constraints (WRT an Ada IR) Date: Thu, 15 Dec 2016 15:53:57 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <999c67b0-4478-4d2b-8108-32ac48fe6316@googlegroups.com> <5cc38920-b746-48f6-87d4-1cf8effa2f02@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:32851 Date: 2016-12-15T15:53:57+01:00 List-Id: On 15/12/2016 15:34, Shark8 wrote: > On Thursday, December 15, 2016 at 1:41:50 AM UTC-7, Dmitry A. Kazakov wrote: > 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. This can mean or apply to just anything. >>> 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. Nothing was lost. - The concept is wrong. - Implementation is of little or no interest. - Representation is no issue. - Ada's dynamic predicates was a mistake. - Type specialization must be supported by more high-level and consistent means (especially with ADT and separation of interfaces). >> 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. I tried to explain why they are different on many levels. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de