Python from Wise Guy's Viewpoint

[Matthias Blume]

Matthew Danish <mdanish at andrew.cmu.edu> writes:

> On Tue, Oct 28, 2003 at 11:20:45AM +0100, ketil+news at ii.uib.no wrote:
> > Matthew Danish <mdanish at andrew.cmu.edu> writes:
> > > What is this stuff?  I am talking about integers here!
> > 
> > But the SML program isn't.  Or it may be, and maybe not.  So it's
> > ambigous without type information.
> > 
> > > Why can't the implementation figure out how to represent them most
> > > efficiently? 
> > 
> > Because it needs a type annotation or inference to decide that the
> > numbers are indeed integers, and not a different set with different
> > arithmetic properties.
> 
> 1 is an integer.  Simple type inference.  In Lisp, it's also a fixnum,
> it's also an (unsigned-byte 23), it's also an (integer 1 (2)), etc.
> 
> > > Lisp gets exact rational arithmetic right, why don't ML or Haskell?
> > 
> > Could you point to a case where they don't?  I don't understand your 
> > criticism at all.  Is the ability to do modulo arithmetic "wrong"?
> 
> - fun fact 0 = 1 | fact n = n * fact (n - 1);
> val fact = fn : int -> int
> - fact 10;
> val it = 3628800 : int
> - fact 15;
> val it = 1307674368000 : int  (* ideally *)

$ sml
Standard ML of New Jersey v110.43.3 [FLINT v1.5], September 26, 2003
- fun fact 0 = 1 : IntInf.int
=   | fact n = n * fact (n - 1);
[autoloading]
[autoloading done]
val fact = fn : IntInf.int -> IntInf.int
- fact 15;
val it = 1307674368000 : IntInf.int
- 

> - 1 * 1.0;
> val it = 1.0 : float  (* ideally *)

That's not "ideal" at all, to me.  I find the automatic conversions in
C a paint in the b*tt because it is not obvious at all where they
happen in a given expression.  How hard is it to write

   real 1 * 1.0

thereby making things explicit, unambiguous, and non-surprising?

Matthias