
On 20 Jan 2008, at 1:02 PM, gwern0@gmail.com wrote:
On 2008.01.19 19:11:13 +0100, Peter Verswyvelen
scribbled 1.4K characters: The problem is that this only works when the complete source file compiles correctly no?
Yes. As I said, it's a very hackish solution - think of it as proof- of-concept.
I would find it most useful to get type inference information on the fly, even when not all of the code compiles correctly yet.
Does that make sense? If the code doesn't compile, then how could any type-inference be trustable? It might be reliable if the error is in definitions which don't get called or otherwise used by the function you are asking after, but there are going to be edge- cases, I should think, where it would bite you.
Even if it's not reliable, the compiler gives its error messages based on some form of partial type inference. It would be quite interesting, some times, to see what the compiler thinks the types are, when it gives a type error (this bit me recently trying polymorphic recursion: I had a long list of polymorphic functions defined without type signatures (since the names were clear enough), factored out some duplicated code, and wound up with a set of mutually recursive functions, one of which was polymorphically recursive. I'll dig the example up if you want (it's kind of compilcated). Knowing that the compiler had various types inferred correctly would have helped me zero in on the place I needed a type signature (or at least I remember wanting to find such things out at the time)). jcc