Python from Wise Guy's Viewpoint

[Andreas Rossberg]

Matthew Danish wrote:
>>
>>Here is a very trivial example, in SML:
>>
>>	20 * 30
>>
>>Multiplication, as well as literals, are overloaded. Depending on 
>>whether you type this expression as Int8.int (8-bit integers) or 
>>IntInf.int (infinite precision integer) the result is either 600 or an 
>>overflow exception.
> 
> May I point out that the correct answer is 600, not overflow?

No, it's not. If I choose type Int8 then I do so precisely for the 
reason that I want to be signalled if some computation overflows the 
intended value domain. Otherwise I had chosen IntInf or something. You 
see, this is exactly the reason why I say that the type system gives you 
expressiveness.

> Something that annoys me about many statically-typed languages is the
> insistence that arithmetic operations should return the same type as the
> operands.

I should note in this context is that static types usually express 
different things than dynamic ones, especially when it comes to number 
types. In Lisp, the runtime tag of a number will usually describe the 
representation of the number. This may well change between operations. 
But static typing, at least in high-level languages, is about semantics. 
If I choose a certain integer type I do so because it has the desired 
domain, which I want to have checked - I'm not at all interested in its 
representation. In fact, values of IntInf are likely to have multiple 
representations depending on their size, but the type is invariant, 
abstracting away from such low-level representation details.

Actually, I think dynamic typing should abstract from this as well, but 
unfortunately this does not seem to happen.

> 2 / 4 is 1/2, not 0.

Integer division is not real division (and should not use the same name).

> Arithmetically, 1 * 1.0 is
> well-defined, so why can I not write this in an SML program?

Because the designers decided (rightly so, IMHO) that it is best to 
avoid implicit conversions, since they might introduce subtle bugs and 
does not coexist well with type inference. But anyway, this has nothing 
to do with static vs dynamic typing - C allows the above, and there 
might well be dynamic languages that raise a runtime error if you try it.

> I do believe Haskell does it right, though, with its numeric tower
> derived from Lisp.

Yes, in Haskell you can write the above, but for slightly different 
reasons (integer literals are overloaded for floating types).

	- Andreas

-- 
Andreas Rossberg, rossberg at ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.