Unexpected NoImplicitPrelude behaviour in GHCi (bug?)

[Claus Reinke]

> I have been experimenting some more with environments for lab work for
> an FP intro course. One thing students tend to have difficulty with in
> the initial labs are the error messages including type classes, or any
> kind of more general type than they expected. I am trying to work around
> this, by supplying a "Number" type for the first lab and gradually
> increasing the complexity over the next few labs. To let all error
> messages be in terms of my type, I use the NoImplicitPrelude option in a
> LANGUAGE pragma. 

Wasn't that the rationale for developing / using Helium?

    http://www.cs.uu.nl/wiki/bin/view/Helium/Features

> However, I find the behaviour of GHCi unexpected. 

There are some oddities in the handling of options/pragmas wrt
GHCi, as discussed in this ticket:

    http://hackage.haskell.org/trac/ghc/ticket/3217

At the moment, and as far as options/pragmas are concerned, 
the GHCi prompt can be seen as an importer of the modules 
loaded. So it needs its own option settings, even if you load
*Main and the Main.hs source code has language pragmas.
This can be confusing (eg, *Main otherwise means "treat
expressions at GHCi prompt as if it was in the Main module").

The consensus in that ticket was that the separation of 
commandline options, GHCi session options, and source
pragmas could be clearer, and there was a concrete 
proposal for a pragmatic implementation plan to improve 
consistency (just waiting for an implementer;-).

Claus