Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!sfk
From: sfk@otter.hpl.hp.com (Steve Knight)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <2400041@otter.hpl.hp.com>
Date: 17 Apr 91 11:30:38 GMT
References: <602@optima.cs.arizona.edu>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 53

Just to expand on Brian Boutel's remarks about statically typed languages
such as ML, HOPE, and Haskell.  He comments:

> The kind of languages I prefer, e.g. ML, Haskell, do not require
> declarations of variables or functions. Types are inferred from the
> context.  [...] So there is really no difference between volumes
> of declarations required in these and in dynamic typed languages like
> Smalltalk.

These languages are completely statically typed & are probably amongst the
best examples of statically typed languages.  The "type inference" mechanism
is guaranteed to find the most general type expression (with a few trivial
caveats).  Dynamic typing is not involved.

However, this compromise is not achieved without a certain cost.  In 
particular, all collections (tuples don't count) are homogenous. This is
a fundamental constraint that allows the type inference mechanism to do
its stuff.  The result of this is that "anonymous" type unions aren't supported.

So if you want to construct a list with an integer and a boolean in it
you write (in ML)
    datatype IntOrBool = Int of int | Bool of bool;
where "Int" and "Bool" are constructors invented by this declaration.  We
can then construct the list as
    val LIST = [Int 3, Bool true, Int 99];

As you can see, although we managed to create a list that roughly corresponds
to our initial specification without any type declarations, we had to invent
a new datatype instead.  I call these type declarations "cosmetic" in that
they mask the type differences of elements in a collection.

These cosmetic type definitions are not as densely used as type declarations
in other statically typed languages such as Pascal, Ada, C, or (to pick a
sensible example) POLY.  But they do proliferate in even relatively moderate
applications.  

It should also be appreciated that type inferencing works well in functional
programming languages, such as ML and Haskell, but is much less effective in
general imperative languages.  This is evident in ML, which has a handful of
imperative features, where the type system becomes considerably less
attrative and more complex.

So programming in a language such as ML is not as comfortable as writing in
LISP, SmallTalk, or Prolog.  But it is certainly a great deal more comfortable
than writing in the other statically typed languages.  (I haven't used Haskell,
so I can't comment on whether or not it is an improvement -- my expectation
is that the "class" layer does provide real benefits -- but that's another
story.)  

Please note that I use the word "comfortable".  By this I am 
implying ease of use for a programmer rather than any other qualities.

Steve