Path: utzoo!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!rex!ames!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: Dynamic typing (part 3)
Message-ID: <18MAR91.08114150@uc780.umd.edu>
Date: 18 Mar 91 08:11:41 GMT
References: <602@optima.cs.arizona.edu> <2837@enea.se>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 58
Nntp-Posting-Host: uc780.umd.edu

Erland Sommarskog writes:
>So when the types don't match, you crash. Sure, this is well-
>defined, but in many application it is just as unacceptable
>as undefined behaviour.

Or you backtrack to some pre-defined point, with a warning, and
continue from there.  Not ideal, but hopefully saving significant work
on the part of the user.  Or if it's a known ill-conditioned case,
maybe you can recover in some other way.

Or, your type int is promoted to type float and you have a little
floating point over-head.

Or, if you really want, you crash... but in an interactive environment
where you have the option of examining the situation right there (with
files still opened and in the same state, for instance), possibly
hand-patching the data and nursing it along to completion, possibly
re-writing a function, popping back a few levels and re-starting, or
possibly you dump core (though it's hardly necessary to call the file
'core').  Not, I'll admit, a requirement in a dynamically typed
language (to support all these options), but much less challenging to
implement than in a statically typed language.  (Dynamic typing makes
dynamic linking somewhat easier, I believe, and in any event, both
seem easy in an 'interpretive' environment.)

>If variables never can be uninitiated in your dynamicly typed
>language, I guess their behaviour can be well-defined.

yep.  If you try and use it with no value, it'll probably (depending
on your language, of course) be a run-time error, with all that
implies (see above).  On the other hand, you can probably also test
it, to see if it has a value...  And there are always code sequences
that guarantee that the variable has a value.

**********************************************************************

Repeat of one of Gudeman's arguments:

When using run-time type checking, practically all type errors are
caught in early stages of testing.

Corollary I:

The software must be tested.

Corollary II:

If the code is ill-conditioned, such that it is likely that invalid
arguments will not show up during testing, the code is poorly written.

(This last is not intended to be proved, but is more on the lines of a
partial definition.)

**********************************************************************

'nuff said?

Raul Rockwell