[darcs-devel] [patch1246] issue822: Improve error message with generalized IO type

Ben Franksen ben.franksen at online.de
Tue Jan 13 17:45:29 UTC 2015


Ernesto Rodriguez wrote:
> Attached is the same patch but that addresses the issue regarding wrong
> error messages as pointed out by Ben.

Thanks. Too bad I already screened your first patch. I would like to ask you 
to send your latest changes as a separate patch (i.e. on top of the one you 
sent last time) if that doesn't bother you too much.

Question for the old-timers: can (do) we obliterate things from screened 
e.g. in a case such as this where someone sends an amended version of a 
patch? Probably not; so what is the standard procedure here: request 
splitting the patch as I just did, or apply the amended version and resolve 
conflicts?

> I agree that type errors become harder to understand when types become
> more general but when such errors occur, it is always possible to
> instantiate the type of a function in where the error is happening and the
> messages will become easy again.

Often things are not that easy. You get a type error somewhere deep inside a 
function and it is not necessarily obvious *which* part of the expression is 
responsible for the whole thing being ill-typed. This is especially 
problematic if multiple overloaded functions are combined in an expression 
because the combination might further constrain the type variables in ways 
that are difficult to guess. Of course, you can factor those parts out, use 
ghc(i) to infer their type etc but this can become really tedious. An 
extreme example for this is the lens library. I have been trying to use 
lenses in several smaller projects and my experience is that as soon as I 
try to do something that goes beyond simple things like accessing parts of a 
record type, I get type errors that are so completely inscrutable (to me, at 
least) that I have to give up sooner or later and go back to using the more 
basic (less overloaded) APIs.

As I said, it's a trade-off, and in the present case I am in favor of 
risking the more general (and more informative) types. Let's see how it 
works out in the long run.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams




More information about the darcs-devel mailing list