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

[Ernesto Rodriguez]

Hi,

> 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.

Sure, attached is the patch. I also elimitated a couple of warnings I just
noticed.

I also wanted to say that the approach I used for having exceptions in the
type can in principle be extended to have as much exceptions one wishes to
mention (by defining more typeclasses) although it can be tedios to do so.
It is not the best approach to achieve this, but the 'state of the art'
approaches would also require significant refactoring so it is the best I
could achieve having only to change a couple of type signatures.

Cheers,

Ernesto

On Tue, Jan 13, 2015 at 6:45 PM, Ben Franksen <ben.franksen at online.de>
wrote:

> 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
>
>
> _______________________________________________
> darcs-devel mailing list
> darcs-devel at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>



-- 
Ernesto Rodriguez

Masters Student
Computer Science
Utrecht University

www.netowork.me
github.com/netogallo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20150114/b1360c47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_http_error.hs
Type: text/x-haskell
Size: 52391 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20150114/b1360c47/attachment-0001.hs>