Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.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.024730.19073@engage.enet.dec.com>
Date: 6 Mar 91 02:47:30 GMT
References: <584@coatimundi.cs.arizona.edu>
Sender: news@engage.enet.dec.com (USENET News System)
Reply-To: grier@marx.enet.dec.com ()
Organization: Digital Equipment Corporation
Lines: 108

In article <584@coatimundi.cs.arizona.edu>, gudeman@cs.arizona.edu
(David Gudeman) writes:
|> 
|> The term "weak typing" has been used for this feature, but it has
|> also
|> been said that Pascal and C are weakly typed languages, so I didn't
|> want to used that word. 

   That's interesting.  I'd certainly agree that C is weakly typed, but
with Pascal requiring name compatibilty of types (rather than
structural, as in C and Modula-2,) I'd put it in the "strong typing"
category.  (Strong typing is not necessarily "good."  Pascal's a neat
language, but it lacks tons of features for modern software
construction...)

|> <stuff about untyped languages>

   This is besides the point, but what's an untyped language then?
If a type defines a collection of values, by definition, every object
in the language has a type, since every value is (reflexively) a
value.  I can't relate to your Icon example, I'm sorry to say it's a
language which is a hole in my readings and experience.

|> 
|> Well, my definition could have been clearer.  I'll make the excuse
|> that everyone I talk to around here has enough experience with these
|> sorts of languages that a quick explanation is enough to let them know
|> what I mean.  I didn't make allowance for different "programming
|> language cultures".  I used the word "polymorphism" to mean "multiple
|> types for the same expression", not "multiple functions with the same
|> name".  However, the term has enough baggage associated with it that
|> it was a poor choice.  I'm going to arbitrarily change my term...

   Ah!  I've always seen polymorphism with respect to functions/
operators/arrows, not necessarily the types themselves.  I couldn't
reconcile your definition, it's much clearer now... :-)

|> <definitions of Static and Dynamic Typing>

   I'm reading a book on Functional Languages right now, and the
language being used as a model is Hope, which is strongly typed,
but where an inference system is used to determine the static typing
of the dynamically typed expression.

   Does this fall into your category?

   It seems to me that with global optimization, you can turn any
seemingly weakly typed expression into a strongly typed one (and
thus eliminate most if not all the inefficiencies which we're
concerned with here.)  The notable exception is what you mentioned:
an operator like "read" where the type of the return value cannot be
determined by static analysis of the program.

   My cut on that is that the value returned from something like
"read" *does* fall into some type, and the return should be treated
by the client as a "refany" is in CLU or Modula-3: you have to apply
a type-case to the value in order to narrow the type of the
expression.

   Is this contrary to your goals?  I'm suggesting something (in a
CLU/Modula-3 like procedural syntax) like:

   x : REFANY;
   BEGIN
      x := read();
      TYPE_CASE x OF
         Integer :
            BEGIN
               /* integer-dependent operations and optimizations */
            END;
         .
         .
         .
         END;
   END;

   Presumably the type_case statement can have an else arm where an
exception could be raised or appropriate actions taken.

   (It's exactly this case of an opacity which can't be determined by
any amount of compile-time static analysis where the inflexibility vs.
inefficiency comes in.  I've never used a "type inferred" language like
Hope myself, but with the exception of this case, it seems usable and
eliminates your worries.)

   The flexibility you desire is/can be obtained by having a type at the
root of the hierarchy (which some consider artificial, others essential,)
which can be used to represent values of any type, and then also a
language operator to perform a modicum of run-time type checking,
permitting significant optimizations within the narrowed scope, which
I believe is the source of your concern.   (There's been a lot of talk
about adding in run-time accessable per-class tags to C++ objects lately,
and it seems to me that if you can perform global analysis, you can
make the run-time checking occur in linear time, costing space n^2
where n is the number of types/classes.)

   Or was it just academic interest in the topic in general?

|> 					David Gudeman
|> gudeman@cs.arizona.edu
|> noao!arizona!gudeman
|> 
------------------------------------------------------------------------
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