On Mon, Sep 26, 2005 at 17:36:04 -0700, Larry Wall wrote:
> Sure, when it slows down your compiler so much that it's useless for
> running code that doesn't have the error, especially if it's a rare
> error that is likely to be caught some other way anyway.  Where to
> balance this should be the decision of the user, particularly since
> the balance point changes over time and space.

Good point... Is there half-way solution, btw?

Perhaps type inferrencing annotation rich areas is a good idea to
help a user who is trying to debug by adding more of these.

> It's also potentially counterproductive if the information available
> at compile time leads to confusingly abstract error messages when
> run-time information might produced clearer concrete error messages.
> When I use the term "confusing", I do so in the Pooh sense.  I'm trying
> to think of what will be confusing to ordinary folks, not to geniuses
> like you.


For the record it takes me roughly 1 irc client or around 10
careful, concentrated rereadings to understand what GHC tells me in
these situations, but for the record.

A useful reference is the Error Messages section on this page:


It mentions both that there are active areas of research on how to
make these better, and that GHC messages both suck and don't suck at
the same time.

 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me dodges cabbages like macalypse log N: neeyah!

Attachment: pgpb2QyvQWJkC.pgp
Description: PGP signature

Reply via email to