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