Hello Ian, Wednesday, January 6, 2010, 2:35:09 PM, you wrote:

Would you find the extra information useful, or just noise? i.e. should we show error spans by default?

i think it's useful in some cases, and don't add noticeable visual overhead in remaining ones -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 06/01/10 11:35, Ian Lynagh wrote:

Currently, when GHC reports an error it only gives a source position, not a source span. For example, with this module:

main = print (f (const 'x' 'x') 'y') f xs y = xs ++ [y]

you get an error starting:

u.hs:1:18: Couldn't match expected type `[a]' against inferred type `Char'

There's a (probably little-known) flag -ferror-spans with which you get this error instead:

u.hs:1:18-30: Couldn't match expected type `[a]' against inferred type `Char'

i.e. rather than just giving the start column number 18, it gives you the span 18-30 (the "const 'x' 'x'").

Would you find the extra information useful, or just noise? i.e. should we show error spans by default?

I think we should point out that this will mean tools that interpret GHC error messages will need to be updated: e.g. Emacs/vim modes. Errors that span multiple lines look like this: Foo.hs:(1,0)-(10,33): ... though the exact format could be changed. I lean towards leaving it turned off. Visual tools that want to turn it on can do so, but using GHC from the command line with a text editor I don't think I've ever wanted to know the endpoint of the expression to which an error message refers, and there are downsides: breaking tools, and extra clutter in the error messages. Cheers, Simon