[Types-sig] Re: Static typing considered ... UGLY

[Paul Prescod]

Edward Welbourne wrote:
> 
> If I implement a datatype (probably as a class) whose objects
> (instances) behave *just the same as* integers in all pythonic respects,
> I demand to be able to use it everywhere that I am allowed to use an
> integer.  If static typing breaks that, it's right out.

It won't break it. Number will be an interface with operations like
"add", "radd", "sub", "mult" and so forth. If you check against the
interface instead of against the type, things just work.

Anyhow, the decision of whether to do this in an interface-y way or a
hard-coded type way is ALREADY up to the author of a module. There are
many places in the standard library where module owners check the types
of objects and return TypeError if they don't get the data they expect. 
It is even more common in the built-in modules. 

How would changing the syntax from 

	def prepend(self, cmd, kind):

		if type(cmd) <> type(''):

			raise TypeError, \

			      'Template.prepend: cmd must be a string'


To:

	def prepend( self, cmd: String, kind ):
		...

make anything worse? And is the latter really "uglier" than the former?
Or do you propose to outlaw the former? Does the mere fact that the
verbose version is essentially useless to the compiler make it more
virtuous?

> the value of the expression being that of the given value, but
> evaluating it'll raise an exception if the typechecker didn't like the
> value.  Now that's a much nicer way to go.  Of course, this effectively
> just amounts to implementing ! as an in-expression assert mechanism ...
> and I'm not entirely sure how it helps the compiler-writer - is that why
> you insist on the typechecker being a dotted name, not an arbitrary
> expression ?

Exactly. Dotted names help the compiler writer and the compiler writer
helps the programmer by finding mistakes and optimizing code. You
scratch my back and I'll scratch yours.

> Please Greg/Fred/Sjoerd, can you write a proposal which starts where
> http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html
> ends (reading the first 9/10 of that was ... illuminating in hindsight,
> but off-putting on the way there).  It looks pretty promising ...

Let me point out again that while that approach is interesting, it
doesn't solve the problem I was recruited to solve: a *static*
*compile-time* checker.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html