Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!liberte From: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Newsgroups: comp.lang.misc Subject: Re: Optional static typing limits Message-ID: Date: 19 Apr 91 19:38:46 GMT References: <2400044@otter.hpl.hp.com> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Urbana-Champaign, NCSA Lines: 55 In-Reply-To: sfk@otter.hpl.hp.com's message of 18 Apr 91 13: 55:15 GMT There seems to be a body of literature out there on better static typing systems (referenced by David Chase) so I am hesitant to say much more before studying the issue. (That hasnt stopped alot of people, of course :-) But let me ask a couple more questions. In article <2400044@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes: > My view is that the key issues for convenience are arbitrary unions and, > by implication, arbitrary subtyping. Are statically declared, arbitrary (anonymous?) supertyping (same as unions?) and subtyping sufficient? They would certainly be helpful in taking care of many static typing problems, but are they always enough? Suppose that for some data it is *impossible* for the compiler or programmer to know what restrictions (i.e. data type constraints) may be placed on the data until run time. Languages that support reflection would be prone to this class of problems, I imagine. Debuggers (that typically reflect on some other process) seem to require dynamic typing, no? If you dont know what constraints may be placed on some data even at run time, then you are out of luck - you dont know what you can safely do with the data and may risk core dumps. Maybe the data knows what its limits are (the object oriented approach) and maybe exceptions are handled gracefully, but obviously something has gone wrong. Speaking of which, is there some study of using exceptions not as errors but as a control mechanism. Consider that when a message is sent to an object and its class does not understand the message, this is a kind of exception. But rather than stopping there, the message is forwarded to the super class, etc. If no class all the way up the hierarchy understands the message, then we give up. But why stop there? Perhaps the original sender would like to try again with a different message. One final thought concerns another kind of convenience argument sometimes given for using dynamic typing. Even when a type is statically known and the language supports its specification conveniently, is it sometimes (or always?) better to not explicitly specify the type? If the type of a variable changes during the course of development, then other uses (but not necessarily all other uses) of the type will often need to be changed to maintain consistency - and this is extra work, especially during early development when many things are changing. Part of this problem could be solved by a better programming environment that helped the programmer mutate the program consistently. Another tack is languages which infer types statically. But how about an explicit (programmer specified) static typing system in which the types are unlikely to change, except for typos? That assumes that once an variable's type is declared, it is most likely the correct type. This doesnt seem possible. Any ideas? Dan LaLiberte National Center for Supercomputing Applications liberte@ncsa.uiuc.edu