Newsgroups: comp.lang.misc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!olson From: olson@juliet.ll.mit.edu ( Steve Olson) Subject: Re: definitions In-Reply-To: tmb@ai.mit.edu's message of 29 Apr 91 22:29:14 GMT Message-ID: Lines: 34 Sender: usenet@xn.ll.mit.edu Organization: M.I.T. Lincoln Lab - Group 43 References: <2494@optima.cs.arizona.edu> <51984@nigel.ee.udel.edu> <333124@socrates.umd.edu> <11525@mentor.cc.purdue.edu> Date: 1 May 91 04:21:06 In article tmb@ai.mit.edu (Thomas M. Breuel) writes: Static typing is added functionality in the compiler. If you want to, you can use dynamic typing on top of a statically typed language, but the converse is not true. Perhaps this statement is correct in many specific cases, but its not correct in general. Common Lisp supports a wide variety of compile-time type declarations. The definition of CL does not force an implementation to use the declarations, but the major UNIX CL implementations do use the declarations. The CL compiler I use (Lucid) is much better at using the decls for optimization than for error checking, but this undoubtably will improve in the future. This lead to s semi-related pet observation of mine -- In general, type errors are quite rare when programming in a Lisp enviroment. How many times do I confuse a pathanme with a array? How many times do I confuse a number and a window? N-E-V-E-R. But a funny thing started happening when I started to optimize the inner loops of some of my CL programs ... I started getting type errors. Getting a integer and a float confused or a single and a double confused is something that does happen quite a bit. To make matters worse, my compiler isn't too great at detecting these types of errors. In this situation I do need static type checking. My contention is that a typical statically typed language causes type errors by forcing the programmer to make micro-decisions about storage layout and machine representation of data. Sometimes you may want to do this for efficiency, but often its a needless burden. -- -- Steve Olson -- MIT Lincoln Laboratory -- olson@juliet.ll.mit.edu --