Devin Jeanpierre <jeanpierr...@gmail.com> writes: > That said, Haskell (and the rest) do have a sort of type coercion, of > literals at compile time (e.g. 3 can be an Integer or a Double > depending on how you use it.)
That's polymorphism, not coercion. The compiler figures out at compile time what type of 3 you actually mean: there is never an automatic runtime conversion. sqrt(3) works because sqrt expects a floating argument so the compiler deduces that the 3 that you wrote denotes a float. sqrt(3+length(xs)) has to fail because length returns an int, so 3+length(xs) is an int, and you can't pass an int to sqrt. > BTW it's weird that in this thread, and in the programmer community at > large, int->string is considered worse than int->float Hehe, though int->string leads to plenty of weird bugs. >> Haskell's idiomatic substitute for a null pointer is a Nothing value > For that matter, how is this (first part) different from, say, Java? In Java, functions expecting to receve sensible values can get null by surprise. In Haskell, if a term can have a Nothing value, that has to be reflected in its type. Haskell's bug-magnet counterpart to Java's null values is Bottom, an artifact of lazy evaluation. E.g. you can write x = 3 / 0 someplace in your program, and the program will accept this and run merrily until you try to actually print something that depends on x, at which point it crashes. -- https://mail.python.org/mailman/listinfo/python-list
