GHCi and line numbers (with ghc-7.4.1)

Simon Marlow marlowsd at
Fri Mar 23 15:28:07 CET 2012

On 22/03/2012 11:36, Christopher Done wrote:
> On 22 March 2012 12:13, Simon Marlow<marlowsd at>  wrote:
>> On 20/03/2012 20:12, Simon Hengel wrote:
>>> They are now incremented with each evaluated expression.
> Why *are* they incremented with each evaluation? Surely the only use
> for line numbers would be in multi-line statements:
>> :{
> Prelude| do x<- [1..10]
> Prelude|    return y
> Prelude| :}
> <interactive>:6:11: Not in scope: `y'
> Would it not make more sense to have
> <interactive>:2:11: Not in scope: `y'
> as it would do if compiling the file in a source file? From the older
> GHCs, this always gives 1, indicating that multi-line statements are
> somehow parsed and collapsed before being compiled, or maybe the line
> number was just hard coded to 1.

One reason for having the line number is that it gets attached to 

Prelude> let x = 3
Prelude> let y = 4
Prelude> :show bindings
x :: Integer = 3
y :: Integer = 4
Prelude> :i x
x :: Integer    -- Defined at <interactive>:20:5
Prelude> :i y
y :: Integer    -- Defined at <interactive>:21:5

I think another reason we added it was so that we could tell when a 
declaration has been shadowed:

Prelude> data T = A
Prelude> :i T
data T = A      -- Defined at <interactive>:25:6
Prelude> data T = B
Prelude> :i T
data T = B      -- Defined at <interactive>:27:6

admittedly it's not a super-useful feature, but if you're dealing with 
multiple bindings with the same name it does give you some confirmation 
that GHC is thinking about the same one that you are.


> FWIW, in my Emacs mode (making good progress on adding to
> haskell-mode) I use the column number in the REPL to highlight on the
> line where the problem is (e.g. here
>, for GHC 7.* with
> proper multi-line support I will automatically wrap any multi-line
> expressions entered in the REPL in :{ and :}, it would be cool for
> line numbers in errors to be useful for that. (Arguably we should be
> using the GHC API and Scion or something like it, but these change
> quite often and are hard to support whereas interfacing with GHCi is
> quite stable across around seven releases and "just works".)
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list