Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!sdd.hp.com!wuarchive!udel!ee.udel.edu From: new@ee.udel.edu (Darren New) Newsgroups: comp.lang.misc Subject: Re: A Hard Problem for Static Type Systems Message-ID: <51984@nigel.ee.udel.edu> Date: 26 Apr 91 22:13:16 GMT References: <2392@optima.cs.arizona.edu> <3156@opal.cs.tu-berlin.de> Sender: usenet@ee.udel.edu Organization: University of Delaware Lines: 108 Nntp-Posting-Host: estelle.ee.udel.edu In article rockwell@socrates.umd.edu (Raul Rockwell) writes: >If C++ is strongly typed because of the lack of this error, then so is >machine language. I'm not sure I see the point of calling this >property "strongly typed". Machine language is weakly and dynamically typed. C++ is (mostly) strongly statically typed. They both have similar effects on "message not understood" errors. Isn't "segmentation violation" a "message not understood" message? It all depends on how you look at it. From the point of view of the programmer who didn't expect this error, this is a type error (e.g., that "mov.l (a4)+,d0" didn't put a long into d0). From the point of view of the OS, usually only bus errors trying to access the interrupt vector are "undefined" resulting usually in a CPU halt which can only be recovered by a reset. >My own definition of "strongly typed" was that the language will not >return a result for applying a function to values which are outside >its domain. Note that except for trivial cases you most definitely >can get "domain errors" (or "message not understood") at runtime. Sounds like a good definition. I'll give some examples below. >Now, I understand that classic works have claimed that a type error is >a value which puts the program in an infinite loop. How else are you going to "not return a value"? >However, I would >say that a language where this happens is weakly typed. In fact, I >think that from this point of view, a "strongly typed" language is one >which only allows finite looping constructs, and which guarantees a >well-behaved "run-time error" whenever a partial function is applied >incorrectly (or maybe we should call this "absolutely typed"?). Terrible example. Smalltalk is "strongly typed" and when you get a type error, the message call does not return any value; instead, it goes into an infinite loop reading the keyboard and interpreting what the debugger says to do and so on. Why restrict yourself to finite looping constructs? Why not just guarantee a well-behaved "run-time error"? Of course, this gets kind of hairy, because the computer never really gets into an infinite loop, so some value is always returned somewhere (unless the computer can never ever be made to work again, at which point the question again appears moot). Hence, when you say "doesn't return a value" you have to clarify it. If I catch "message not understood" have I returned a value or have I had a type mismatch or both? This is part of the confusion in this discussion. Let's use these definitions, or at least choose *some* definitions before we start another round of "yes it is"/"no it isn't". (Somebody want to save these so I don't have to keep reposting the definitions?:-) Dynamic typing (one more time for the expiration-impaired :-): syntactic elements (like variables or expressions) do not have types. Static typing: syntactic elements (like variables or expressions) do have types and these types can be determined at compile time. It doesn't matter whether the use specifies the types implicitly or explicitly or a combination of both. It *does* matter that each variable is supposed to hold one type of data only, and the representation of that data is assumed to be known at compile time. Strong typing: values of the wrong type cannot be stored into accessors (i.e., lvalues, function parameters, etc) and functions may not be applied to values outside of their domain without a compiletime or runtime error. (Note: a catchable runtime error (or exception), like "message not understood" in Smalltalk, is not a runtime error. A non-catchable error, like "new" running out of space in Pascal, is a runtime error.) Values of the wrong type are assumed to possibly have incompatible representations; i.e., valid integers may not be valid floats, etc. Weak typing values of the wrong type can be stored into accessors and/or functions may be applied to values outside their range without an immediately detectable error. Examples of all four combinations: Static weak typing: K&R (pre-ANSI C) Array subscripting, bad pointers, passing int's as float's into separately compiled functions, etc, etc, etc are all not caught, but each and every syntactic value-carrying expression (function calls, variables, etc) has a declared or determinable type. Static strong typing: Modula-3 (safe subset) There are no operations (supposedly) which cause the wrong type of value to be stored into a variable; variables are initialized to legal values; dangling pointers cannot dangle, etc. Dynamic weak typing: Most machine languages (as seen from the OS point of view) The same memory location can hold both integers or addresses, and checks are not made that the value is used in the right way. Dynamic strong typing: Smalltalk Every operation returns a defined result for every value, yet no variable or function needs to know the "type" it will hold, explicitly or implicitly. (Note again that "message not understood" in Smalltalk is a defined catchable error and therefore returns a value.) -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+ Nails work better than screws, when both are driven with hammers +=+