🚀 go-pugleaf

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.

>> 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.

>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.

-- 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.