Newsgroups: comp.lang.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Run-time Type Errors in Smalltalk
Message-ID: <1991Apr17.202034.13268@Think.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <2023@optima.cs.arizona.edu>
Date: Wed, 17 Apr 91 20:20:34 GMT

In article <2023@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
>What can you say about errors that occur in  production code in
>dynamically typed languages?  First, they are not caused by the
>necessity of getting around the static type checker.  Second, they are
>almost never type errors of the sort that could have been caught by a
>static type checker.  Third, if they are type errors they cannot cause
>a core dump or other unpredictable behavior.

The above assumes that a dynamically typed language always does type
checking.  Common Lisp, for instance, does not require runtime type
checking.  The following has unpredictable behavior:

(rplaca (read) 3)

If the input does not contain the representation of a cons then it has
undefined behavior, and can core dump, corrupt the Lisp image, or launch a
nuke.

A static type checker could flag this as a potential type error, but it
shouldn't disallow the code.  If the input is coming from the user I'd
consider the above to be poor code, but if it is coming from a
machine-generated source that is "guaranteed" to have the representation of
a cons, then it is safe; for instance, the following is fine:

(with-input-from-string (*standard-input* (format nil "(~S)" object))
  (rplaca (read) 3))

is guaranteed to return the same thing as

(list 3)

or signal a read-error if OBJECT doesn't have a readable printed
representation.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar