Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!brian
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <1991Apr11.053440.13401@comp.vuw.ac.nz>
From: brian@comp.vuw.ac.nz (Brian Boutel)
Date: Thu, 11 Apr 1991 05:34:40 GMT
Sender: news@comp.vuw.ac.nz (News Admin)
References: <1707@optima.cs.arizona.edu>
Organization: Computer Science, Victoria University, Wellington, NewZealand
Nntp-Posting-Host: antrim-hse.comp.vuw.ac.nz
Originator: brian@antrim-hse.comp.vuw.ac.nz
Lines: 50


In article <1707@optima.cs.arizona.edu>, gudeman@cs.arizona.edu (David
Gudeman) writes:
|> In article  <1991Apr9.110217.10963@mathrt0.math.chalmers.se> Lennart
|> Augustsson writes:
|> ]  map f [] = []
|> ]  map f (x:xs) = f x : map f xs
|> 
|> I'm getting really tired of pointing this out: the program above
|> does
|> not have the full generality of the mathematical or the dynamically
|> typed version.  This is a point I've made several times on several
|> Haskell and ML programs, and I wish people would get the idea so I
|> could stop repeating myself.  The statically typed program only
|> works
|> on structures in which all elements have the same type -- and only
|> when the compiler can infer that type.
|> 
|> Type inference has some nice features, but it does _not_ give you
|> the
|> expressive power of dynamic typing.

Let us suppose that we apply a function f to a list in which not all
elements have the same type, and let us suppose further that by some
stroke of luck all the elements of the list "understand" something with
the name f, so in mapping f through the list there is no exception or
failure, and we get a new list. What useful operations can we then
perform on the result list? We know nothing about its members, except
that they all can all be the result of applying a function called f to
something or other, which is not very helpful.

Even if these values can tell you their own types, you can't write code
to deal with all possibilities unless you know in advance what types can
occur, in which case you can use a statically typed language, declaring
a type which is a discriminated union of the possible types in the
list.

Any problem solution can be programmed in a statically typed language,
if the programmer is prepared to *design* the program before writing it.
I would be far more confident trusting my life/safety/money to such a
program than to some piece of hackery written in a language where
"expressive power" is more important than solid engineering principle.

--brian

-- 
Internet: brian@comp.vuw.ac.nz
Postal: Brian Boutel, Computer Science Dept, Victoria University of Wellington,
        PO Box 600, Wellington, New Zealand
Phone: +64 4 721000   Fax: +64 4 712070