[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