Unexpected NoImplicitPrelude behaviour in GHCi (bug?)
claus.reinke at talk21.com
Thu Jun 10 10:15:15 EDT 2010
> 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?
> 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:
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;-).
More information about the Glasgow-haskell-users