Path: utzoo!news-server.csri.toronto.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!m2c!umvlsi!dime!yodaiken From: yodaiken@chelm.cs.umass.edu (victor yodaiken) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 3) Message-ID: <27816@dime.cs.umass.edu> Date: 12 Mar 91 19:31:27 GMT References: <609@optima.cs.arizona.edu> Sender: news@dime.cs.umass.edu Reply-To: yodaiken@chelm.cs.umass.edu (victor yodaiken) Organization: University of Massachusetts, Amherst Lines: 34 In article <609@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes: >In article <27794@dime.cs.umass.edu> victor yodaiken writes: >]When I write: >] let S be a set >] let f:S -> X >] let Y = f(S) and let Z = {g(s): for s IN Y} >] for each s in S let k_s = f(S) >] >]a human being could figure out that: >]... that the last line makes more sense if we interpret f(S) as a typo >]that should really be f(s) > >A human is a lot smarter than a static type checker. A static type >checker can only tell you there is an inconsistency between the >declaration of f and its use. It doesn't know which is the error. > >]How is a dynamically typed programming language going to figure this >]out? > >A dynamic language might tell you more than the static language does, >given that you actually execute this code. During the execution of f >you will probably call some function on the argument that is only >defined for sets, and you will get an appropriate error message >telling you what value should be a set and isn't. > I'm agnostic on this issue, but your argument is very unpersuaive. Won't a runtime type language attempt to do something sensible with the error, something that might obscure the error, but leave it lying around for later? If the language decides to apply f to each element of S,then I may get a perfectly reasonable value for my test data, but suffer from mysterious errors at some future date. I'll come up with a more worked out example if needed.