Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Message-ID: <5012@goanna.cs.rmit.oz.au>
Date: 20 Mar 91 06:51:12 GMT
Article-I.D.: goanna.5012
References: <602@optima.cs.arizona.edu> <9106@castle.ed.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 44

In article <9106@castle.ed.ac.uk>, aipdc@castle.ed.ac.uk (Paul Crowley) writes:
> I'm going to split languages in two by type extensibility.  In C and ML,
> you can explicitly make up a new type from old types: a widget is made
> up of two foos and a bar.  In Logo, there are only three types: words,
> numbers, and lists.  If you want to define an imaginary number, you
> could use a list of two integers.  If you want to define a UNIX-style
> time as a list of two integers [secs, usecs], you can do that too.  If
> you accidentally feed an imaginary number to a function that wants a
> date, the language won't say a word.  Prolog behaves this way too. 

Just an observation here:  any Prolog programmer who chooses such
representations should be kicked in the backside until he or she
does it *right*.  A better way to represent complex numbers would be
as "tagged pairs"
	complex(RealPart, ImaginaryPart)
and a better way to represent times would be
	time(Seconds, MicroSeconds)
These cannot be confused with each other.  They also use 3/4 of the
memory that a two-element list would use.  In fact, with the DEC-10
Prolog type checker, you would declare

	:- type complex --> complex(number,number).
	:- type time --> time(integer,integer).

and have all the reliability benefits of static type checking (but
not the efficiency benefits).

What's more, there isn't one teeny tiny thing in C (or, for that
matter, ML) which *makes* you use separate types.  In C
	struct num2 { double x[2]; };
	struct num2 i = {0.0, 1.0};	/* a complex number */
	struct num2 t = {1.2, 0.0};	/* a time */
When you think of the number of conceptually distinct types which
C programmers overlay onto 'int', you realise that "static typing"
*may* fail to buy you much reliability.  Note the way that C,
most Pascals, and many Fortrans overlay the notion "bit vector"
onto integers.

One great *reliability* advantage of languages like Lisp is that
there is no equivalent of casts (or for PL/I fans, no UNSPEC).
There _is_ a typing system and you _can't_ defeat it.

-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.