Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!opal!wg From: wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) Newsgroups: comp.lang.functional Subject: Re: A question about types in ML Message-ID: <2215@opal.cs.tu-berlin.de> Date: 15 Nov 90 18:00:17 GMT References: <4906@rex.cs.tulane.edu> Sender: news@opal.cs.tu-berlin.de Reply-To: wg@opal.cs.tu-berlin.de Followup-To: comp.lang.functional Distribution: comp Organization: Technical University of Berlin Lines: 32 Nntp-Posting-Host: troll.cs.tu-berlin.de 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. There is no meaningful expression which has no type. In the case of lists consisting of values of different type, functions must exist defined over all instances of the "untyped" list in a given program to give meaning to the list. Thus the values of the list must have some common property (a type). In the very rare case, this property is to be just an object; in most other cases, the property will be much more specific: e.g. to be a number, a (graphic) view, etc. >Because such restrictions [on signatures] handcuff the programmer, >one line of reseach seeks to develop restrictions >for decidablilty which maximize polymorphism. Yes. The pragmatic problem for the design of a strongly-typed language maximizing polymorphism (regarding to ML polymorphism) is that its much harder for a programmer to keep track of sophisticated decidability restrictions then of (in a way) "syntacticly" expressable restrictions like non-recursive signatures. And the type-checker must handle undecidable problems, e.g. must avoid its own non-termination, still giving comfortable error reports. -- Wolfgang Grieskamp wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET