Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!mantis!mathew
From: mathew@mantis.co.uk (mathew)
Newsgroups: comp.lang.misc
Subject: RE: Dynamic typing (part 3)
Message-ID: <Tw4H18w164w@mantis.co.uk>
Date: 16 Apr 91 14:39:40 GMT
References: <15APR91.00424359@uc780.umd.edu>
Organization: Mantis Consultants, Cambridge. UK.
Lines: 63

cs450a03@uc780.umd.edu writes:
> Curious.  Sounds to me like ML and Haskell are [at least partially]
> dynamically typed.  [I presume by "do not require declarations" you
> mean "do not require declaration of 'type' or 'storage class'" -- I
> can't quite see you not having to declare any values :-) ]

What ML actually does is to infer types from information given implicitly.
For example, if you define a function f(x) = x + x, we can infer that f(x) is
a function from some type 'a to a value of the same type 'a ( 'a -> 'a ),
since we know that + is of type 'b * 'b -> 'b.

If we then define a function g(y) = f(f(y)), we can infer that y must be of
type 'a (in order to be a valid argument for f()) and hence that g(y) is a
function 'a -> 'a.

If we then do  z = sin(g(0.2)), we can infer that type 'a must in fact be
a floating-point number, since we know that sin is of type float -> float.

Using such rules, ML cleverly deduces the type of functions without your ever
having to explicitly state the type. It then does static compile-time type
checking. (Apologies to ML experts if I've glossed over anything or made any
silly errors; I haven't used ML in quite a while.)

In order to allow this sort of deduction to take place, you must place
certain limitations on what is allowed. For example, if you were to allow
heterogeneous lists, you would be unable to deduce a single type for any
list, leading to dead-ends in the type deduction.

Sometimes it can be necessary to state a type explicitly, if there isn't
enough information in the code for ML to deduce what you intend.

It is always permissible to state the type explicitly if you wish to do so;
although doing so removes most of ML's benefits.

> I claim that a language that inserts run-time checks on the values
> which are applied to functions, and only removes these checks where
> static analysis of the code shows them to be redundant, is going to
> catch more errors than a language which does not.

Indeed. One of the most stupid things which people do is to remove all the
run-time checking from released versions of programs, even when the programs
are not time-critical.

> I claim that a language which allows a programmer to specify an
> operation concisely is going to result in better productivity (in
> terms of bug-free functionality produced) than a language which always
> requires the programmer to deal with trivial details of the
> implementation.

Agreed. I also think that a language which allows features such as (for
example) heterogeneous lists is, in certain applications, going to result in
enormously greater programmer productivity. Why use unions and implement your
own type system using tags, when you can use a type system which is already
there?

If only we could solve the problem of generalized lambda-2 typing, we might be
able to have a statically-typed language which was as powerful as Lisp...


mathew

--
If you're a John Foxx fan, please mail me!