🚀 go-pugleaf

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.