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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Making sense of predicates Date: Wed, 23 Oct 2013 11:25:23 +0200 Organization: cbb software GmbH Message-ID: <34g5l1787w2f$.1fnf8eraqqbpy.dlg@40tude.net> References: <87iowprctp.fsf@adaheads.sparre-andersen.dk> <7d18f68a-f15e-4e81-bbbe-22010c513a84@googlegroups.com> <0eb80b2f-696e-45cd-9e6c-724ce3866f79@googlegroups.com> <1d57t46pwft4z$.ktho2ymc6bso$.dlg@40tude.net> <1fc36959-9863-4720-b772-6b4f064d4b6b@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: IenaDxMXK2hi7fvYcb+MlQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3967 Xref: number.nntp.dca.giganews.com comp.lang.ada:183711 Date: 2013-10-23T11:25:23+02:00 List-Id: On Tue, 22 Oct 2013 14:30:15 -0700 (PDT), Dan'l Miller wrote: > On Tuesday, October 22, 2013 2:26:28 PM UTC-5, Dmitry A. Kazakov wrote: >> On Tue, 22 Oct 2013 10:15:13 -0700 (PDT), Dan'l Miller wrote: >>> Ahhhh, you seek effectively the C++ vision, >> >> No idea what makes you think so. > > And that is unfortunate, because I told you above. I reiterate: The A#1 > mantra of major sectors of the C++ community (e.g., Boost) is to perform > functionality in libraries whenever possible instead of in the core C++ > language. But this is not specific to C++, it is just a good language design principle, which C++ does not follow anyway. I merely responded to Randy's moan about the ARM's section about the accessibility rules. To handle complexity you have to say good-bye to monolithic design. Specifically regarding the accessibility rules, there is no chance one could make them sensible. Pointers cannot be made safe. Period. Investing into safe pointers is wasting time. One should rather do into means helping the programmer to avoid pointers. Instead of that Ada introduced access to subprogram, access discriminants, anonymous access etc. What did you guys expect doing so? >>> What you seek is a better way of layering the compiler and extending the compiler, >> >> I seek a better types system because of problems the current one causes, >> like overuse of generics and run-time checks. I, as a programmer, need more >> static checks, more reuse, far less debugging. > > Dmitry, please take a hint: your type goals would be satisfied as a mere > library by-product of accomplishing a much much MUCH more difficult goal > of taming the beast of layered compilers that accomplish multistage > programming, So the point is that the type system is all OK? Or maybe you are with Randy and others who believe that though it is not OK, but nothing substantial could be accomplished and it is better to start a new language from scratch, but we rather won't? [...] The reason to have it in a library is backward compatibility. Now about fragility et al. Consider the subtype Positive. It is a library thing defined in the standard library: subtype Positive is Integer range 1..Integer'Last; Note that the language does not need Positive because it already has a more generic mechanism of constrained subtypes which library uses. Now, try to apply your points about fragility to Positive. Carefully observe that while applications using Positive are indeed fragile. The reason for that lies in the Positive itself. It is a target-dependent [sub]type and thus ill-defined in a wider context of multiple targets. This fragility is not because there is something wrong with Ada's subtypes! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de