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!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed2.news.rcn.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> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> <87eklg62x8.fsf@news.bourguet.org> From: jayessay Organization: Tangible Date: 07 Sep 2004 14:20: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=F\\PWdUK6MJXH7>k6?ZMSO0R]m=BkYWIG:6bU3OT9S9JhCF8eBK1g5C^aM2i8keRmMP@cY7i=:66I X-Complaints-To: abuse@rcn.com Xref: g2news1.google.com comp.lang.ada:3445 Date: 2004-09-07T14:20:36-04:00 List-Id: Georg Bauhaus writes: > jayessay wrote: > : Georg Bauhaus writes: > > > :> What do you mean by robust? > : > : Both type checks and logic errors are checked simultaneously and at > : very fine grained levels. > > And static type checking can't add, at least in many relevant > cases? In some scenarios it can indeed add a certain level of confidence. I think most dynamic type folks (certainly most everyone over on c.l.l) would look at it something like this: "Static typing can indeed provide some value. Dynamic typing provides an enormous level of value. If I could have static typing without it destroying the value provided by dynamic typing, I'd take it. But the two are fundamentally at odds in what they _need_ in order to _provide_ what they offer. > :> If a translator sees a function call, where the function has a > :> specific formal T parameter, and the translator can do type checking > :> before running this piece of the program, doesn't this remove the > :> necessity to test a number of code paths in the first place? > : > : That is often insufficient because it doesn't ensure anything about > : whether the _content_ of a value conforming to the type is correct for > : the input of the function. > > Sure it is insufficient. But it adds value by removing the need to > test what the compiler has already found out. How about typos? True. But since this is determined anyway as part of incremental development it doesn't actually save anything in practice. Typos are a good example. > Here is a fake: > > (defun next (n) (1 + n)) > (defun hext (n) (1 + (mod n 16))) Let's see this in practice: (defun next (n) (1+ n)) ==> next ;; let's try it (dotimes (i 10) (let ((n (random 100000))) (format t "~%(next ~a) --> ~a" n (next n)))) ==> (next 97872) --> 97873 (next 73063) --> 73064 (next 74426) --> 74427 (next 84763) --> 84764 (next 45797) --> 45798 (next 82856) --> 82857 (next 35267) --> 35268 (next 732) --> 733 (next 90138) --> 90139 (next 73850) --> 73851 (defun hext (n) (1+ (mod n 16))) ==> hext ;; prove it: (dotimes (n 17) (format t "~%(hext ~a) --> ~a" n (hext n))) ==> (hext 0) --> 1 (hext 1) --> 2 (hext 2) --> 3 (hext 3) --> 4 (hext 4) --> 5 (hext 5) --> 6 (hext 6) --> 7 (hext 7) --> 8 (hext 8) --> 9 (hext 9) --> 10 (hext 10) --> 11 (hext 11) --> 12 (hext 12) --> 13 (hext 13) --> 14 (hext 14) --> 15 (hext 15) --> 16 (hext 16) --> 1 Hey, hext is broken ;; fix it (defun hext (n) (mod (1+ n) 16)) ==> hext ;; prove it: (dotimes (n 17) (format t "~%(hext ~a) --> ~a" n (hext n))) ==> (hext 0) --> 1 (hext 1) --> 2 (hext 2) --> 3 (hext 3) --> 4 (hext 4) --> 5 (hext 5) --> 6 (hext 6) --> 7 (hext 7) --> 8 (hext 8) --> 9 (hext 9) --> 10 (hext 10) --> 11 (hext 11) --> 12 (hext 12) --> 13 (hext 13) --> 14 (hext 14) --> 15 (hext 15) --> 0 (hext 16) --> 1 That's better. (defun advance (n) (hext n)) ; a slip of the finger ==> advance ;; try it (dotimes (n 17) (format t "~%(advance ~a) --> ~a" n (advance n))) ==> (advance 0) --> 1 (advance 1) --> 2 (advance 2) --> 3 (advance 3) --> 4 (advance 4) --> 5 (advance 5) --> 6 (advance 6) --> 7 (advance 7) --> 8 (advance 8) --> 9 (advance 9) --> 10 (advance 10) --> 11 (advance 11) --> 12 (advance 12) --> 13 (advance 13) --> 14 (advance 14) --> 15 (advance 15) --> 0 (advance 16) --> 1 Hey, this is broken. Looks like hext was used when I wanted next! Or ;;; Pre condition: N a number ;;; Post condition: result = (1+ N) ;;; (defun advance (n) (check-type n number "a number") (let ((result (hext n))) (assert (= result (1+ n)) nil (format nil "ADVANCE: Post condition (= RESULT (1+ N)) failed; ~ [~A /= ~A]" result n)) result)) > Oops. Types could help I'd say. What you are saying is, range types (as in Ada) could have caught this. True, but they would not have caught it quicker (or even as quick) as this did. Also, they wouldn't have caught the error in hext until you ran it anyway. > I know that Lisp values are of a type. But I simply don't see how > declaring the type of a function (via arguments), say, can't be a win. > What will the ML programmers say? They will (more or less) agree with you. Of course they will go further and claim that things like Ada/Eiffel/C++/Java/etc have lame type systems and that what you buy with a true formal type system (like one based on say, Hindley-Milner) makes dynamic arguments less potent/interesting/valuable/whatever. > : (assert x any-type "a value of type any-type") > > : (declaim (ftype (function (a-type) N) foo)) > : (defun any (x) ...) > > Does this hinder incremental testing? No. /Jon -- 'j' - a n t h o n y at romeo/charley/november com