Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!jit533!diamond From: diamond@jit533.swstokyo.dec.com (Norman Diamond) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 31,497) Message-ID: <1991Apr26.021037.16284@tkou02.enet.dec.com> Date: 26 Apr 91 02:10:37 GMT References: <2046@optima.cs.arizona.edu> <1991Apr24.051522.28988@tkou02.enet.dec.com> <24APR91.08062530@uc780.umd.edu> Sender: usenet@tkou02.enet.dec.com (USENET News System) Reply-To: diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo Lines: 75 David Gudeman Norman Diamond Raul Rockwell dg>>>... static typing implies ... all expressions can be assigned types dg>>>from a restricted set ... such that machine representations can be dg>>>decided on at compile time nd>>Yes. dg>>> and such that no type information has to dg>>>be associated with a value at runtime. nd>>No. rr>No, "type information has to be associated with a value at runtime" ? Type information might or might not be needed at runtime, depending on the type. Actually did not distinguish between static typing and static classing, since no one else seems to be interested in distinguishing these. rr>Then what is dynamic typing? From what I've seen in this argument, dynamic typing is the absence of programmer specification of types. rr>Or, was this a statement that "constant type tags can be assiciated rr>with a value at runtime"? If so, it is far from a clear statement. Why would type tags have to be constant? nd>>Why not both [dynamic and static typing] ? rr>"Both" is, by definition, not static typing -- such a language would rr>allow you to express statements which can not be statically typed. Indeed, "both" means that the language would allow you to express statements which cannot be statically typed, and also statements which can be statically typed, and also statements which are constrained to static types by administrative fiat. rr>On the other hand, it is often a simple matter (of strength reduction) to rr>extract static typing information from statements in a dynamically rr>typed language. "Often" is the key word in that sentence. It is often possible to write C programs without the use of "void *", but someone decided that "often" isn't "often enough." >One distinction is that in a dynamically typed language type >assertions are "just another operator" and most likely will use the >same syntactic conventions as other language operators. Oh, this sounds like a "both" ... haven't seen one of those yet. >In statically >typed language this does not have to be the case, and usually is not. Once upon a time, "uniformity of reference" was a buzz-phrase. People liked Fortran and PL/I better than Algol because array element selection looked like function calls, and they would have liked structure selection to look like function calls too, so that the client would not have to "know" the kind (I don't want to say "type" this time) of structuring involved to retrieve the data. However, the Pascal and C style of square brackets for arrays and dot for structures (and parentheses for function calls) seems to have won. I like it too. It seems to reduce confusion. I think that to use different syntax to distinguish static properties of an entity from its dynamic properties also might reduce confusion. >This was hashed out in comp.lang.misc about a month ago, though it >might not have been expressed fully in any one article. Sorry, I wasn't reading comp.lang.misc then. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.