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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!news-FFM2.ecrc.net!rcn!feed3.news.rcn.net!not-for-mail Sender: jsa@rigel.goldenthreadtech.com Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request References: <49dc98cf.0408110556.18ae7df@posting.google.com> <87eklg62x8.fsf@news.bourguet.org> From: jayessay Organization: Tangible Date: 09 Sep 2004 21:01:36 -0400 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: DXC=9fk>Um]oVD\DY84Z?F] Georg Bauhaus writes: > jayessay wrote: > > : Yes, and they don't happen at runtime if pre and post are checked > : during incremental development. If you don't do this, then you will > : likely have problems - just like if you don't get the types right in > : static languages. > > Is it really much more time efficient, if pre and post checking is done > by an incrementing human? If so, how much? Generally, yes. For two general reasons: 1. you are always sure of the logic as well as the type consistency 2. You don't have global "system integration" issues as each incremental step subsumes an integration aspect. > : Your explanation above does not cover the logic error. I don't see > : right off how modular types catch that. > > See below, there isn't a logic error, only a typo. No, I'm not talking about the typo in the advance function. I'm talking about the logic error in the Hext function itself! > > : with Text_Io; use Text_Io; > : > : procedure Foo is > : > : type Hex_Num is mod 16; > : > : function Hext (N : Integer) return Hex_Num is > : begin > : -- == (1+ (n mod 16)), which is the logic error. > ^^^^^^^^^^^^ not really, see below > : return Hex_Num(1 + (N mod Hex_Num'Modulus)); > : end Hext; > : > : begin > : for I in 0..20 loop > : Put_Line("Answer is: " & Hex_Num'Image(Hext(i))); > Put_Line("Answer is: " & Integer'Image(Hext(i))); > : end loop; > : end; > > In the Lisp example there was a "typo context". "next" should have > been where "hext" was actually typed in the Lisp example That's not the logic error. The logic error is that Hext is broken due to the incorrect expression at the line noted above. > Therefore, an integer number was actually wanted ("next"), not > a hex number ("hext"). > So there must be an Integer'image reflecting the logic/expectation > ("next") not a Hex_Num'image (typo "hext"). > The error is caught by the compiler. > > 15. Put_Line("Answer is: " & Integer'Image(Hext(i))); > | > >>> expected type "Standard.Integer" > >>> found type "Hex_Num" defined at line 4 No. This would be a different (brain fart) type of error. The logic error is in Hext - it does not correctly compute the residue class defined by Hex_Num!!! This is shown by the Ada RT raising constraint error - even though the compiler didn't (indeed _couldn't_ complain about the definition!!!). /Jon -- 'j' - a n t h o n y at romeo/charley/november com