Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!udel!rochester!kodak!islsun!cok From: cok@islsun.Kodak.COM (David Cok) Newsgroups: comp.lang.misc Subject: Re: Run-time Type Errors in Smalltalk Message-ID: <1991May17.221539.22844@kodak.kodak.com> Date: 17 May 91 22:15:39 GMT References: <1991May16.134106.24421@daffy.cs.wisc.edu> <1991May16.175340.25522@kodak.kodak.com> <1991May17.045347.26722@daffy.cs.wisc.edu> Sender: news@kodak.kodak.com Organization: Eastman Kodak Co., Rochester, NY Lines: 118 In article <1991May17.045347.26722@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: >In article <1991May16.175340.25522@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes: >>In article <1991May16.134106.24421@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes: >>>For instance, I recently spent more than a couple of minutes figuring out >>>what was wrong with a C program with this fragment: >>> >>>{ >>> ... >>> double f, foo; >>> int i; >>> >>> ... >>> >>> f = modf(foo, &i); >>> ... >>> switch (i) { ... } >>>} >>> >>>The point is, I don't care what numeric type i is. In a dynamically typed >>>language this type error would not occur. >> >>It seems to me it still would: if modf returned for you an i which was a double >>and the switch statement knew only how to handle int's, you would get a >>runtime error because of mismatched types. (If you allow for smarter switch >>statements or implicit conversion, you've changed the comparison to one of >>flexibility of the type system rather than static vs. dynamic typing.) >> > >Yes. I'd get an error _and_an_error_message_ the first time I tried the code. >C gives me no error message, just the wrong answer. IMHO the lisp behavior >is infinitely better in this regard. Are you actually defending silently >giving the wrong answer to "Error in switch: expected an int but got a double" >?????? This bug gets fixed in a dynamic language in the first pass, utterly >trivially. What makes you so certain that the programmer would even know >that the C version was bugged? No error messages are given. What if the >program just happens to give the expected answers on the test cases despite >the bug? I'd consider this an overwhelming victory for the dynamically typed >language. Guarranteed to find the bug, trivial to fix. C, good luck. > No I am absolutely not defending the idea of "silently giving the wrong answer to "Error in switch: expected an int but got a double"' Read a little more carefully. C is a bad comparison, as I point out, because it has so many holes in its type checking. I was asking for a comparison between a dynamically typed language and a strongly statically typed language. They both would show the error (one a run-time and one at compile-time). I'm not advocating one or the other here (and certainly not advocating C) -- just trying to understand the benefits and drawbacks of different systems. >>> In dynamically typed languages >>>a lot of things that can be type errors in static languages simply *cannot* >>>cause errors. >>I believe that most dynamically typed languages have more flexible type >>systems than most statically typed systems, but I need convincing on the >>point above. >>.... The same set of errors would occur. So I do not >>understand why "a lot of things that can be type errors in static languages >>simply *cannot* cause errors [in a dynamically typed language]". >> > >This point is very simple, but perhaps not obvious. For an example I'll use >the X Toolkit again. > > int width; > XtVaGetValues(widget, XtNwidth, &width, NULL); > >will compile fine and run without giving any error diagnostics. (For those >not familiar with the X Toolkit, XtVaGetValues is a procedure that takes a >widget object and a varargs list of name, value pairs and retrieves those >properties from the widget. In order to handle properties of many different >types, the values are type XtPointer which is (usually) caddr_t. This is a >black hole as far as type checking goes.) The problem is that the correct >type of an XtNwidth property is Dimension, (which is often) not int. This >is a type error and C doesn't catch it. In lisp there is no type error. >The type is latent, stored with width. If the X Toolkit decided that XtNwidth >should be a bignum there would be *no* changes required to the lisp code. >In the unlikely case that other lisp code makes the erroneous assumption that >width is an int the error will be detected and I'll get an error message. > Again your example does not fill the bill -- you pick one where the type checking is turned off, i.e. a weakly typed system. If you want to argue that no current statically typed language is flexible enough to do the right things with variable length argument lists -- you do not have to convince me. But don't say that you do not get type errors in dynamically typed languages -- you do; what you don't get are uncaught type errors -- that's a plus -- at run-time -- that's a minus. >>one was statically typed and the other dynamically typed. The dynamically >>typed language would catch all type errors at runtime, presumably with good >>diagnostics about just what variables and types and functions were involved. >>The statically typed system would catch some type errors at compile time. >>The ones it did not catch would cause difficult to find errors -- at least >>they do in traditional C. The same set of errors would occur. So I do not >>understand why "a lot of things that can be type errors in static languages >>simply *cannot* cause errors [in a dynamically typed language]". >> > >See above. The same set of errors do not occur. And remember, many difficult >to find errors simply aren't found and the product goes out the door. The same set of errors do not occur in *C* -- no argument on the fact that C's type checking is abysmal and type errors go out the door. > >-- Doug Quale >quale@saavik.cs.wisc.edu > >P.S. The C compiler won't even give an error diagnostic if you omit the NULL >at the end of of the varargs argument list. You do get the very handy >"Segmentation fault -- Core dumped" diagnostic when you try to run it. >A language with more flexible and robust argument passing is a lot nicer. Agree with the last sentence -- just wondering how to make that language as statically typed as possible without overly restricting flexibility. David R. Cok Eastman Kodak Company cok@Kodak.COM