Unexpected NoImplicitPrelude behaviour in GHCi (bug?)

"Philip K.F. Hölzenspies" p.k.f.holzenspies at utwente.nl
Tue Jun 15 07:28:55 EDT 2010


Dear Claus, et al.

I've already responded in more detail in another e-mail on the seemingly inconsistent behaviour of GHCi, but I also wanted to respond to your points here.

On Jun 10, 2010, at 4:15 PM, Claus Reinke wrote:

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

This is true. Having said that, I find GHC's error messages to be reasonably good and I find GHC as a compiler to be better. Also, I don't believe very much in their philosophy. I don't think teaching aides that tell a student precisely what to do are necessarily better. The only downside (from a teaching point of view) of GHC's error messages, is that you have to know and understand so much of Haskell to read them. I want GHC's error messages, but just restricted to non-typeclass issues. I'm hoping this will stimulate students to actually read the error messages. Once they're confident that they're actually really informative, I don't mind when they get a little messy ;)

> 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

Thanks for the pointer.

> 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").

I agree; I would like *Main to mean "it's as if you're now inside 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;-).

Mmm... time :(

Regards,
Philip


More information about the Glasgow-haskell-users mailing list