Thanks for the suggestions, George. May I suggest that a good place for these things is the "Feature Requests" tracker on the GHC SourceForge page - otherwise good suggestions tend to get lost if we don't implement them immediately.

I am using .hi-boot files quite a lot at the moment. I'm very grateful for the recent change to a more Haskelly syntax, but I have a couple of suggestions for the GHC team to implement in their no doubt ample free time. 8-)

(1) Importing a module {-# SOURCE #-} into itself currently produces a warning, but no other action so far as I can see. I suggest instead that this provoke a check that the .hi-boot module accurately reflects reality. (Otherwise there is no way of checking is there?) Or perhaps you could add a pragma {-# RECURSIVE #-} at the top of the module that indicates the presence of a .hi-boot file which should be checked.

We'd like to do something like this, but there's no simple hack that gets us there quickly. One for the feature requests page.

(2) Instance declarations (with empty bodies) should be permitted.

Tricky, because an instance declaration in an interface has to name the dictionary function, and currently dictionary functions are given weird internal names (that might not be the only stumbling block). But we would like to do this.

(3) There should be an option to pass .hi-boot files through cpp. This would not be particularly useful to me, as I have already implemented a pre-compilation phase which does just that, but it might be useful for others.

I'd say just use Makefiles for this.

(4) The manual should recommend using say the GHCi :info command to find out that, say, IO must be called GHC.IOBase.IO. (If I'd known this it'd have saved me having to trawl through the GHC sources.)

Good point. I'll add a note to the docs.

Obviously one would ideally be able to type IO rather than GHC.IOBase.IO, but my guess would be that this would be (a) harder to implement than the other suggestions, (b) less useful.

We looked into this, but couldn't find an easy way to do it.

Happy New Year by the way. If any Simon is still reading, about long have we got before the current old library hierarchy is done away with in an official release? Sometime before then I will need to carry out a massive global-exchange.

I'd planned to remove hslibs in the next major release, but that might prove to be too soon - especially since hslibs still contains some stuff that hasn't moved over to the hierarchy yet. So it will probably be the next-but-one major release; as usual, feedback from you folks out there is welcome. Cheers, Simon