GHCi and line numbers (with ghc-7.4.1)

[Simon Marlow]

On 22/03/2012 11:36, Christopher Done wrote:
> On 22 March 2012 12:13, Simon Marlow<marlowsd at gmail.com>  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 
declarations:

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

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.

Cheers,
	Simon



> 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
> http://chrisdone.com/images/hs-repl-error-demo.png), 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 haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users