🚀 go-pugleaf

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