Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!rex!wuarchive!usc!julius.cs.uiuc.edu!apple!snorkelwacker.mit.edu!ai-lab!ai.mit.edu!tmb
From: tmb@ai.mit.edu (Thomas M. Breuel)
Newsgroups: comp.lang.functional
Subject: Re: A question about types in ML
Message-ID: <11901@life.ai.mit.edu>
Date: 15 Nov 90 21:50:03 GMT
References: <fraser.658398987@melomys> <4906@rex.cs.tulane.edu> <2215@opal.cs.tu-berlin.de> <4971@rex.cs.tulane.edu>
Sender: news@ai.mit.edu
Reply-To: tmb@ai.mit.edu
Distribution: comp
Organization: MIT Artificial Intelligence Lab
Lines: 24

In article <4971@rex.cs.tulane.edu>, fs@caesar.cs.tulane.edu (Frank Silbermann) writes:
|> >>		Because compromise between flexibility and safety
|> >>		will always involve a trade-off, I believe that
|> >>		untyped functional languages (e.g. those in the
|> >>		LISP/Scheme style) will never become completely obsolete.
|> 
|> >	In the very rare case, this property is to be just an object ... 
|> 	       ^^^^^^^^^
|> If you remove the imperative features from the core of Common Lisp,
|> and remove the features which allow function definitions
|> to be disassembled as lists, what remains _can_ be viewed
|> as a functional language in which all expressions
|> denote elements of the recursive domain
|> 
|> 	D = (Atoms + Booleans + DxD + D->D)_bottom.

Of course, you can use ML in the same way:

datatype D = Atom of string | Bool of bool | Int of int |
	     Real of real | Cons of (D * D) | Vector of (D array)

But, at least in ML you have the option of using strong typing,
whereas in CommonLisp (or other dynamically typed languages),
there is no language support whatsoever for handling typing.