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: Tue, 9 Dec 2014 09:51:07 +0100 Organization: cbb software GmbH Message-ID: <1hrw1i0f6nyde.1obvidset2kfc$.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> <1adpj5cs8xtkf$.hqv9tsofbfgz$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: YGNMlxhiQ90vAyH0QA4qPw.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:23919 Date: 2014-12-09T09:51:07+01:00 List-Id: On Mon, 8 Dec 2014 16:45:51 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1adpj5cs8xtkf$.hqv9tsofbfgz$.dlg@40tude.net... >> On Wed, 3 Dec 2014 15:41:12 -0600, Randy Brukardt wrote: > ... >>> 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. > > Not practical. I explained why later. > >>> 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) > > By this definition (which is not the typical definition of the phrase), any > realistic program is weakly-typed. Possibly, it depends on many factors including willingness to make the type system aware of types beings logically different (= non-substitutable). Regarding custom definitions of weak typing, it is usually a lot of hand waving without much substance. >> 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. > > Not at all. C has no run-time checks; you'll never get any sort of error > from it unless you write it explicitly yourself. I'm never going to have > enough fortitude to write thousands of pages of checks by hand; I've got to > have language support to make those checks. Yes, but we are discussing bugs, not errors. When you say that an exception manifests a bug, then C is as good as Ada. The same bug in C will show itself differently, but so what. Now, if you *anticipate* an Ada run-time check to fail, you also handle this fault appropriately in the program and it is no more a bug, and no more a type error. The point is that when you do not do that it is same as you would go in C and, hence it is C programming in Ada. And reversely, if you expect a type error in C and add checks to verify for that (= for non-substitutability) and then handle the result, that would constitute Ada programming in C. (:-)) > In any case, your vision of strong typing (which is many times stronger than > what I could stand) is completely impractical for me. I tried it in the Claw > builder, and the result is very hard to extend. To add a new kind of window > object, one has to write implementations for roughly 80 primitive > subprograms; roughly 5000 lines of code. To add a new capability, one has to > add implementations of new primitive operations to all of the existing kinds > of window objects (around 20 at last count). Either of those takes multiple > days of work before anything can be compiled. Since I'm "agile" to my core > (and long before such a thing even had a name), spending more than 4 hours > or so writing anything without a compile/run/test cycle is scary. Especially > as I can't really remember what I did if it goes longer than that; debugging > takes much longer if more code is involved. (In such a case, you have to > re-remember what your plan was for particular problems -- it's much more > like debugging existing code than something you just finished writing.) > > Anyway, I think we just have to agree to disagree on this one. Not really disagree. I know too well how difficult is to describe complex relationships between types in Ada. Which is why I wished Ada's type system were improved. > My goal is to bring more static detection of what are formally run-time > errors in Ada. Sure. But note, that SPARK or similar is not a replacement to typing. It is a completely different thing aimed at correctness of a singular program instance. Type safety is aimed at implied correctness of a multitude of possible programs. Both are important because the latter is much more constrained. > I don't think calling that "typing" is helpful in any way, > because the mechanisms are so different. YMMV. Singular proofs profit greatly from an elaborated type system. What could SPARK do for C? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de