3 ms·

> Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. I may be wrong, but I suspect you don

> Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. I may be wrong, but I suspect you don't know how Haskell type inference works. (1) This is just semantics, but the compiler is not "smart" and does not "figure out" types. It uses a straightforward type unification algorithm (should feel natural to anyone who's programmed in Prolog) with a monomorphism restriction. (2) The type annotations you add may be different than the types that the compiler would deduce in their absence, and these annotations may in fact be necessary in order for the program to be correct. Your question about Lisp has already been answered, but I will expand. The type checking can be done at runtime, at compile time, or at some combination of both—it is not always possible to deduce the type of function arguments at compile time in a language like Lisp. Obviously, (+ 1 "ABC") is an error, but not all situations are so obvious. The same is true in Python, Ruby, JavaScript, Objective C, Java, Haskell, and any other language which supports dynamic typing. Yes, Haskell supports dynamic typing.

jerf 13y ago
"This is just semantics," Yes, it is. That entire paragraph was... less than useful. "Yes, Haskell supports dynamic typing." Yes, it does, but not with any of the features you've discussed. It supports it with Data.Dynamic. Type holes are still as I described; they are not a way to escape the type system or make it compile something that does not have some sort of concrete type, they are a way of asking the compiler what type it thinks goes somewhere. Here, the first hit for "ghc type holes": http://www.haskell.org/haskellwiki/GHC/TypeHoles http://www.haskell.org/haskellwiki/GHC/TypeHoles "This is the purpose of a hole: it has similar semantics to undefined, in that evaluating it is an error (you can replace all holes with undefined, and vice versa, and nothing has changed: you may even say undefined is just a really crappy, useless hole!) But it's special in that when GHC encounters a hole during compilation it will tell you what type needs to be there in place of the hole, for the type-checker to be OK with the definition." This is not dynamic typing. It may superficially look like it if you just gloss over the definition, but if you really understand it that's not what it is. There is still some sort of concrete answer (concrete to the type system, for which constraints aren't that big a deal). I return fire: I suspect you don't understand how Haskell type inference works, since you're making false claims about these features.

jerf 13y ago

"This is just semantics," Yes, it is. That entire paragraph was... less than useful. "Yes, Haskell supports dynamic typing." Yes, it does, but not with any of the features you've discussed. It supports it with Data.Dynamic. Type holes are still as I described; they are not a way to escape the type system or make it compile something that does not have some sort of concrete type, they are a way of asking the compiler what type it thinks goes somewhere. Here, the first hit for "ghc type holes": http://www.haskell.org/haskellwiki/GHC/TypeHoles http://www.haskell.org/haskellwiki/GHC/TypeHoles "This is the purpose of a hole: it has similar semantics to undefined, in that evaluating it is an error (you can replace all holes with undefined, and vice versa, and nothing has changed: you may even say undefined is just a really crappy, useless hole!) But it's special in that when GHC encounters a hole during compilation it will tell you what type needs to be there in place of the hole, for the type-checker to be OK with the definition." This is not dynamic typing. It may superficially look like it if you just gloss over the definition, but if you really understand it that's not what it is. There is still some sort of concrete answer (concrete to the type system, for which constraints aren't that big a deal). I return fire: I suspect you don't understand how Haskell type inference works, since you're making false claims about these features.