Python from Wise Guy's Viewpoint

Joachim Durchholz joachim.durchholz at web.de
Tue Oct 28 07:07:05 EST 2003


Matthew Danish wrote:

> On Mon, Oct 27, 2003 at 10:08:15PM +0100, Joachim Durchholz wrote:
> 
>>Matthew Danish wrote:
>>
>>>On Mon, Oct 27, 2003 at 07:00:01PM +0100, Andreas Rossberg wrote:
>>>
>>>>Pascal Costanza wrote:
>>>>
>>>>>Can you show me an example of a program that does't make sense anymore 
>>>>>when you strip off the static type information?
>>>>
>>>>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, the correct answer isn't 600 in all cases.
>>If it's infinite-precision arithmetic, the correct answer is indeed 600.
>>If it's 8-bit arithmetic with overflow, there is no correct answer.
>>If it's 8-bit arithmetic with wrap-around, the correct answer is 88.
>>If it's 8-bit arithmetic with saturation, the correct answer is 255.
>>(The result happens to be independent of whether the arithmetic is 
>>signed or unsigned.)
> 
> What is this stuff?  I am talking about integers here!  You know, the
> infinite set with the same cardinality as natural numbers.  Why can't
> the implementation figure out how to represent them most efficiently?

Hey, that 20*30 expression given above didn't say what type of integer 
arithmetic was meant, or did it?

>>Of course, this doesn't say much about the distinction between static 
>>and dynamic typing, actually the issues and unlucky fringe cases seem 
>>very similar to me. (In particular, overloading and type inference don't 
>>tell us whether the multiplication should be done in 8-bit, 16-bit, 
>>machine-precision, infinite-precision, wrap-around, or saturated 
>>arithmetic, and run-time types don't give us any useful answer either.)
> 
> Lisp gets exact rational arithmetic right, why don't ML or Haskell?

They do as well - infinite-precision integers are standard issue in 
these languages.

It's just that Andreas's answer to the challenge of presenting a 
type-dependent expression was simpler than anybody would have expected. 
Of course, if your best response is that this all is ill-defined when it 
isn't - then, I fear, you'll simply have to stay on your side of the fence.

Regards,
Jo





More information about the Python-list mailing list