Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!paperboy!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <25317:Mar2803:26:1291@kramden.acf.nyu.edu>
Date: 28 Mar 91 03:26:12 GMT
References: <1162@optima.cs.arizona.edu>
Organization: IR
Lines: 55

In article <1162@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
> The examples of heterogenous lists posted by others are persuasive,
> more so than I would have expected.  Other examples include the
> ability to define polymorphic functions easily:
>   procedure max(a,b) return if a < b then b else a; end

#define max(a,b,lt) ((lt)((a),(b)) ? (b) : (a))

Or

any max(a,b,lt)
any a;
any b;
int lt();
{
 if (lt(a,b))
   return a;
 else
   return b;
}

>   procedure string_to_num(s) # returns the integer or float
>   # represented by s.  In case of an error, the return value is a
>   # string describing the type of error.
> Statically typed languages either need a global variable or an
> exception handling mechanism to do this.  And with the global variable
> method, the programmer can forget to check the value of the global,
> leading to undefined behavior.  With the solution above, forgetting to
> check the result will eventually lead to a type-error that will
> probably be much easier to track down.

But an exception handling mechanism obviously produces the best results:
you need to take positive action to catch the exception, so if you
forget to handle it then you're guaranteed to get an error. In contrast,
``will eventually lead to a type-error'' is not particularly comforting.
Your program may be doing something entirely different in the meantime,
and lots of other data may be corrupted.

> (1) dynamic typing
> is useful enough that it should be supported directly by programming
> languages,

Supported, yes; but why does the support have to be direct? Why can't it
just be a set of library routines, plus the syntactic sugar necessary to
make you happy?

> (4) it is not clear the the ability of
> static type declarations to catch errors outweighs the number of
> errors that occur in the declarations.

Fair enough. However, just in case the benefits of static typing *do*
outweigh the errors---possibly by a lot---doesn't it seem wise to
provide the support?

---Dan