🚀 go-pugleaf

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.

Why should a programming language be expected to catch this type of
error at compile time, and not some other class of errors?  Why are
type errors so special?  There are many other sorts of errors that
could be detected at compile time by requiring enough work from the
programmer.  They aren't checked because it is rightly seen that the
extra work outweighs the potential benifits.  The same is true of type
declarations, which is obvious to everyone who programs in a language
without them.  Required declarations are not in languages because they
are a good idea, they are an accident of history.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman