On 20 Jan 2008, at 1:02 PM, [EMAIL PROTECTED] wrote:
On 2008.01.19 19:11:13 +0100, Peter Verswyvelen <[EMAIL PROTECTED]>
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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe