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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to get nice with GNAT? Date: Sat, 6 Dec 2014 13:02:28 +0100 Organization: cbb software GmbH Message-ID: <1adpj5cs8xtkf$.hqv9tsofbfgz$.dlg@40tude.net> References: <969708583438656051.436159nonlegitur-futureapps.invalid@reader80.eternal-september.org> <0d085a5a-d4ac-4506-ae5f-8da685f39004@googlegroups.com> <1ukyfvaqgkwo1.6ngfx1v21twz$.dlg@40tude.net> <1g5ttpzi8eywc$.1gluj9evlmeus.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: yUABN/t9m6vXD7XrfDICJA.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 Xref: news.eternal-september.org comp.lang.ada:23897 Date: 2014-12-06T13:02:28+01:00 List-Id: On Wed, 3 Dec 2014 15:41:12 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:hz0z7hi7czmw$.1qfhyt5f4awot.dlg@40tude.net... >> On Mon, 1 Dec 2014 16:25:28 -0600, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:1g5ttpzi8eywc$.1gluj9evlmeus.dlg@40tude.net... >>> ... >>>> The idea that all/most/some bugs should somehow manifest their wrong >>>> behavior in exceptions is dubious. >>> >>> Fascinating. I'd say the reverse: that almost all bugs quickly manifest >>> themselves in an exception (at least in well-designed Ada code). For >>> instance, I tend to make off-by-one errors in index calculations. Such >>> errors almost always result in a Constraint_Error when the index is used. >> >> The index may slip toward another side. Why do you expect that any wrong >> index would always be out of the range? > > "Any wrong index"? I never said that. At some point, the off-by-one error > will be out of the expected range and a Constraint_Error will result. Which is a very specific kind of all bugs which may happen with index calculation, a quite infrequent one in Ada. > And that will directly show the problem. Ada has quite good means to ensure this never to happen. In my practice I can remember only one or two cases I got "subscript error". I believe the possibility of such bug could be significantly reduced if Ada's renaming were fixed, e.g. if you could slide indices per renaming and have other safe means to "translate" indices of one array into indices of another. >>> Similarly, in Janus/Ada, we've sometimes passed the wrong entity to a >>> subprogram; that almost always shows up as a Constraint_Error detecting >>> the use of a non-existent variant. (If a routine expects a symboltable >>> pointer to an object, and gets a package, the components it needs aren't going to >>> be there.) >> >> In such cases I just use tagged types. The problem here is in weakly-typed >> design, which makes run-time type errors possible. > > Huh? The thing passed is an access-to-a-symbol, which is an > access-to-variant-record in an untagged design, or an > access-to-class-wide-symbol in a tagged design. The subprogram you pass it should have been a primitive operation. > Either way, you'll get a run-time error. Yes, because it is weakly-typed. I would even dare put up a definition: Typing is weak when type errors are run-time errors (Untyped is when type errors are run-time bugs) > In Ada 2012, you could use a predicate on the parameter in > order to make the check sooner, but it still will be a runtime check. And this still be weakly-typed, which is why dynamic predicates are so dangerous. They add nothing but another possibility for having a bug. > In may experience, most problems come down to managing combinations of > several kinds of objects (in the abstract sense, not the Ada sense), and > it's not sensible to try to do that in any sort of statically typed manner. Which is using Ada as if it were C. The combinations of objects should be handled in a way allowing to map combinations onto the language items allowing static checks. Yes, it is not always possible, and where not possible it becomes a C program in Ada, partially of course. > (Especially in Ada, where only one inheritance tree can be primitive, but > it's also true in general, because there are too many combinations to deal > with.) Which is why MI and MD are needed so badly. > Strong typing is great to eliminate gross errors (like passing an > expression node when a symbol entry was meant -- as both are represented as > access types, they can easily be confused), but it's not going to catch the > lower-level mistakes. This is true because typing cannot express all the semantics and thus some semantic errors will slip through. But that does not justify not using typing where possible. >> The point is that bugs in a legal program may expose any behavior [within >> of possible]. There is no way to predict this behavior and thus hoping that >> it would become an exception or setting some variable in some way is dubious. >> >> SPARK or any language design would not change this, the bugs they catch >> are caught, which is good, but the rest will act as it always does. > > Of course, no technology could ever catch every bug. But the point here is > to reduce the universe of legal possibilities, hopefully to the limit so > that either an exception is raised or the program works as designed. Note > that the latter still could in fact be buggy, because a lot of programs work > as designed but still don't do what they are supposed to do (at the human > level). No technology could ever eliminate that case, as such it's not worth > even talking about other than to acknowledge its existence. Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de