Python from Wise Guy's Viewpoint

[Erann Gat]

In article <3638acfd.0310231647.16db77b4 at posting.google.com>,
rafe at cs.mu.oz.au (Ralph Becket) wrote:

> myfirstname.mylastname at jpl.nasa.gov (Erann Gat) wrote in message
news:<myfirstname.mylastname-2310030857350001 at 192.168.1.51>...
> > 
> > No.  The fallacy in this reasoning is that you assume that "type error"
> > and "bug" are the same thing.  They are not.  Some bugs are not type
> > errors, and some type errors are not bugs.  In the latter circumstance
> > simply ignoring them can be exactly the right thing to do.
> 
> Just to be clear, I do not believe "bug" => "type error".  However, I do
> claim that "type error" (in reachable code) => "bug".

But that just begs the question of what you consider a type error.  Does
the following code contain a type error?

(defun rsq (a b)
  "Return the square root of the sum of the squares of a and b"
  (sqrt (+ (* a a) (* b b))))

How about this one?

(defun rsq1 (a b)
  (or (ignore-errors (rsq a b)) 'FOO))

or:

(defun rsq2 (a b)
  (or (ignore-errors (rsq a b)) (error "Foo")))


> Here's the way I see it:
> (1) type errors are extremely common;

In my experience they are quite rare.

> (2) an expressive, statically checked type system (ESCTS) will identify 
>   almost all of these errors at compile time;

And then some.  That's the problem.

> (3) type errors flagged by a compiler for an ESCTS can pinpoint the source
>   of the problem whereas ad hoc assertions in code will only identify a
>   symptom of a type error;

Really?  If there's a type mismatch how does the type system know if the
problem is in the caller or the callee?

> (4) the programmer does not have to litter type assertions in a program
>   written in a language with an ESCTS;

But he doesn't have to litter type assertions in a program written in a
language without an ESCTS either.

> (5) an ESCTS provides optimization opportunities that would otherwise
>   be unavailable to the compiler;

That is true.  Whether this benefit outweighs the drawbacks is arguable.

> (6) there will be cases where the ESCTS requires one to code around a
>   constraint that is hard/impossible to express in the ESCTS (the more
>   expressive the type system, the smaller the set of such cases will be.)
> 
> The question is whether the benefits of (2), (3), (4) and (5) outweigh 
> the occasional costs of (6).

Yes, that's what it comes down to.  There are both costs and benefits. 
The balance probably tips one way in some circumstances, the other way in
others.

E.