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: 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> <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@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