Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!munnari.oz.au!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: <5048@goanna.cs.rmit.oz.au>
Date: 25 Mar 91 09:05:27 GMT
References: <602@optima.cs.arizona.edu> <2400034@otter.hpl.hp.com> <8078@skye.cs.ed.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 31

In article <8078@skye.cs.ed.ac.uk>, db@cs.ed.ac.uk (Dave Berry) writes:
> >- val foo = [false, 0];
> >Error: operator and operand don't agree (tycon mismatch)
> 
> There's no way that you can know the type of the head of a list
> containing both integer and booleans without either:
> 
> 	1. Dynamic typing.
> 	2. Tagging each element.

Alan Mycroft wrote a paper in the early 80s about adding dynamic
typing to languages like ML in a fully type-safe way.  (Basically,
dynamically typed values are "tagged".  To get at a particular
value you had to use something like a conformity-case.)

> >It is not possible to write a polymorphic hash-function.
> 
> I don't see how it's possible to write a polymorphic hash-function in any
> language unless you know all the possible types or type-representations
> that the language will ever have, at the time when you write the function.

In the case of something like Lisp, we do know all the possible type
representations.  There is no particular reason why ML couldn't have
a built-in polymorphic "hash" function that applies to any "equality"
type.  Abstract data types are a problem, but if you can replace '='
for a data type you can replace 'hash' for it as well.  (Lisp has a
short-cut here which ML lacks; a hash function in Lisp has to
approximate EQ rather than EQUAL.)

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