Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.object Subject: Re: Do we really need types in OOPL's? Message-ID: <1990Oct5.055232.15051@odi.com> Date: 5 Oct 90 05:52:32 GMT References: <0yw10qr@Unify.Com> <411@eiffel.UUCP> <736@tetrauk.UUCP> <1990Oct2.230958.16544@cbnewsc.att.com> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 56 In-Reply-To: lgm@cbnewsc.att.com's message of 2 Oct 90 23:09:58 GMT In article <1990Oct2.230958.16544@cbnewsc.att.com> lgm@cbnewsc.att.com (lawrence.g.mayka) writes: Dynamically typed languages such as Common Lisp and Smalltalk perform incremental compilation and loading, so the delay in the edit-compile-debug cycle is near-zero. Compile-time typing is precisely what *requires* those long edit-compile-debug delays that are so intolerable in conventional large software systems. Actually I think it's a bit more complicated than that. You could imagine a language like Lisp or Smalltalk in which the program could be annotated with various assertions, which would be like little statements that say "if the type of X is not integer, signal an error now". You could put assertions on variables, and such a little if statement would autoamtically be generated upon each assignment. You could also add assertions for argument and returned values. Then, you could make the compiler understand these assertions and attempt to optimize them out at runtime. For example, if "x" is asserted to have only integer values, the expression (setq x (+ x 2)) (for you C people that means "the statement x += 2") would not need any actual runtime checks. (For now let's ignore any overflow issues.) Next, you teach the compiler that when it sees a call to a function foo, it looks for foo's argument assertions and foo's return value assertions, and these things get utilized by the aforementioned optimization. It's not so hard for the environment to know the assertions of a called function. The Symbolics interactive environment already is capable of looking at a called function to see how many arguments it expects, so that it can notify you at compile time if you pass the wrong number of arguments. Well, this is just an extension of the same sort of mechanism. Finally, you have your choice as to whether making these assertions is purely optional (you add them wherever you want to), or totally mandartory (every variable, every argument, every return value must have an assertion). Of course, since all types are subtypes of other types, and all types are subtypes of the uber-type T (in Lisp), you could always assert that something was of type T, which would be a null assertion (true by definition) (easy to optimize!). Contrariwise, it is possible to write an incremental environment for C, as witness Sabre. Of course, there are things in C that make a real incremental compiler rather hard to do, like the C preprocessor. But as long as it's used sparingly, the incremental environment shouldn't have too much trouble. (Lisp has a similar issue with reader macros, solved by the fact that they're not used very much.) I'm not saying that everything is equal to everything. There are big differences of all sorts between languages and between environments. All I am trying to say here is that the differences may not be as fundamental as they seem, and there is all kind of room for compromise and/or getting the best of both worlds, or for getting those parts of each world that you like best.