Newsgroups: comp.lang.misc
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!olson
From: olson@lear.juliet.ll.mit.edu ( Steve Olson)
Subject: Re: Dynamic typing (part 3)
In-Reply-To: yodaiken@chelm.cs.umass.edu's message of 7 Apr 91 03:55:34 GMT
Message-ID: <OLSON.91Apr9012119@lear.juliet.ll.mit.edu>
Sender: usenet@xn.ll.mit.edu
Organization: M.I.T. Lincoln Lab - Group 43
References: <28875@dime.cs.umass.edu> <49907@nigel.ee.udel.edu>
	<28924@dime.cs.umass.edu> <OLSON.91Apr6155734@lear.juliet.ll.mit.edu>
	<28937@dime.cs.umass.edu>
Date: 9 Apr 91 01:21:19


In article <28937@dime.cs.umass.edu> yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:
   In article <OLSON.91Apr6155734@lear.juliet.ll.mit.edu> olson@lear.juliet.ll.mit.edu ( Steve Olson) writes:
   >
   >In article <28924@dime.cs.umass.edu> yodaiken@chelm.cs.umass.edu (victor yodaiken) writes:
   >   The problem with "untyped" expressions is that they are inherently
   >   ambiguous. If I'm writing about  semigroups and regular languages I must
   >   tell you when a*b is concatenation and when it is semigroup addition.
   >   Figuring this out from the context alone is difficult for most people.
   >
   >This sounds more like overuse of operator overloading rather than anything
   >having to do with static vs. dynamic typing.  This problem could occur just as
   >easily in C++ as in CLOS.  If you never want to mix the two types then 
   >renaming the operators will remove all confusion.  If you do want to mix the
   >two types then the problem is the same whether you are using a dynamically
   >typed language or a statically typed sortof-dynamic-typing-through-subclassing-
   >and-virtual-functions language.


   I don't want to have to give up overloading --
   one of the real conveniences of mathematical notation. But if I declare
   variable types, there is no problem.
   So, if I write: let a,b be elements of the alphabet and
   let a',b' be the corresponding elements of the semigroup, then
   a*b and a'*b' are easy to distinguish. By making the types of the
   variables explicit, I make the overloading of * unambiguous. An
   expression a*b' where the two variables have different types makes no
   sense in this context and I'd like the compiler to catch it.


You know, my line about renaming the operators was a little weak; let me
try to do better.  First of all, you may want to mix the two, not in your
core routines, but in support code that manipulates container classes.  This
is the old heterogeneous list problem, already hotly discussed on this list.
Most solutions to this problem from the static typers are based on subclassing
and virtual functions, which, as I orginally noted, lands you back where you 
started.  

Second, using a type system to either provide documentation or to catch
errors (you arguments seem to center around this) is overrated.  Just how
often do you mistakenly confuse variables of totally different types?
Everybody's experience is different, but for me the answer is virtually
never.  My viewpoint is that static typing *creates* the potential for type
errors by demanding all sorts of diddly-squat decisions about is this number a
int,float,double, or whatever.  This can lead to efficiency gains, but it
seems like a far cry from the concept of mathamatical type you have
been talking about in other posts.

I am aware that demanding detailed decisions about storage layout or machine
data-types is not inherent to the concept of static typeing.  I would be 
interested in hearing about a language where you could do something
like declare x to be a "number".  Does such exist?  Efficiency aside, does
there exist a language where a static type system catches lots of errors but
dosen't get in your way the way current examples do?  I don't know myself
-- thats why I read this list!

- Steve Olson
  MIT Lincoln Laboratory
  olson@juliet.ll.mit.edu

