Suggested improvements to .hi-boot files

[Simon Marlow]

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=20
> very grateful for the recent
> change to a more Haskelly syntax, but I have a couple of=20
> suggestions for the GHC team
> to implement in their no doubt ample free time. 8-)
>=20
> (1) Importing a module {-# SOURCE #-} into itself currently=20
> produces a warning, but no other action
> so far as I can see.  I suggest instead that this provoke a=20
> check that the .hi-boot module accurately
> reflects reality.   (Otherwise there is no way of checking is=20
> there?)  Or perhaps you could add a
> pragma {-# RECURSIVE #-} at the top of the module that=20
> 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=20
> cpp.  This would not be particularly useful
> to me, as I have already implemented a pre-compilation phase=20
> 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=20
> command to find out that,
> say, IO must be called GHC.IOBase.IO.  (If I'd known this=20
> 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=20
> ideally be able to type IO rather
> than GHC.IOBase.IO, but my guess would be that this would be=20
> (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,=20
> about long have we got before the=20
> current old library hierarchy is done away with in an=20
> official release?  Sometime before then=20
> 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