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