🚀 go-pugleaf

In article <46686@nigel.ee.udel.edu>, new@ee.udel.edu (Darren New) writes:
|> <stuff deleted>
|> 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