Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shlump.nac.dec.com!engage!marx.enet.dec.com!grier From: grier@marx.enet.dec.com Newsgroups: comp.lang.misc Subject: Re: Dynamic typing -- To Have and Have Not (was Runti Message-ID: <1991Mar6.184410.26168@engage.enet.dec.com> Date: 6 Mar 91 18:44:10 GMT References: <584@coatimundi.cs.arizona.edu> <1991Mar6.024730.19073@engage.enet.dec.com> <46686@nigel.ee.udel.edu> Sender: news@engage.enet.dec.com (USENET News System) Reply-To: grier@marx.enet.dec.com () Organization: Digital Equipment Corporation Lines: 74 In article <46686@nigel.ee.udel.edu>, new@ee.udel.edu (Darren New) writes: |> |> Also, in an `untyped' language, expressions return values (which have |> types) but since the same static expression can return values of |> different type, the expression itself cannot be siad to have a specific |> type. For example, Smalltalk allows arrays to have values of different |> types in different positions of the array. Hence, x := (array at: 5) is |> not a specific type, even though at any given time that expression will |> return a value of a given type and assign that value to x. x will |> nevertheless be untyped. Contrast with C, wherein one says (x = |> array[4]). Depending on the declaration of `array', I can tell the type |> of the value array[4]. I can also know the type of the variable x. Ok, that makes sense. (I confess to not doing much in Smalltalk, probably a cardinal sin among OO folk.) But, at any given instant, the variable does represent a value which is a member of a given class. Even in expressions which are "untyped" (such as x := (array at: 5),) a globally scoped optimizer *could* infer the type of x. (Sounds to me like it's similar to a computability/halting- problem type of issue when you get into nontrivial recursive situations, but I haven't read that part of my func. lang. book yet... :-) In fact, it can always infer the type of the expression, although there are probably cases where a more general type is computed than the actual class of the value. (For instance, you could always punt and say "it's an Object". That's not very useful in aiding efficiency though... :-) Something that occurred to me is "what's the point here?" If the issue is to see what you *can* and *can't* do efficiently in an untyped/dynamically typed language, like I said, it seems related to the complexity and difficulty of the halting problem. There's no algorithm which is going to be able to infer the result type of an expression in all instances, but it seems like for many important ones, there are solutions. (The article posted to either comp.arch or comp.lang.c about optimizing Scheme, I believe it was, is a good example of what CAN be done, even if a single solution can't cover all cases. The point about the halting problem comes from some postings by Dan Bernstein where he claims a solution to the halting problem. What he *does* is solve a significant and useful portion of it, which is interesting. What's been proved is that every algorithm which will definitely produce an answer in finite time will have to make one of three decisions - halts, doesn't halt, can't determine. The "can't determine" seems very similar to "ummm... it's an Object!" in inferring the type of an expression.) I was approaching the issue with my engineering hat on, and looking at what problem was trying to be solved. My preference is towards strongly typed languages with mechanisms like I've outlined where the type can be strengthened within a given scope and so additional inferences about operations can be made. But if the desire is for discussion and academic interest, my ideas have little bearing, except that perhaps it's not a very fruitful or useful branch of study. (Of course that's what a lot of people have said about different branches of Mathematics which end up turning up in the strangest places explaining observed phenomonea.) |> |> Well, I hope that clears that up, and that I haven't misrepresented |> what was being said. -- Darren |> |> -- |> --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- |> ----- Network Protocols, Graphics, Programming Languages, |> Formal Description Techniques (esp. Estelle), Coffee, Amigas ----- |> =+=+=+ Let GROPE be an N-tuple where ... +=+=+= |> ------------------------------------------------------------------------ I'm saying this, not Digital. Don't hold them responsibile for it! Michael J. Grier Digital Equipment Corporation (508) 496-8417 grier@leno.dec.com Stow, Mass, USA Mailstop OGO1-1/R6