Urgh, that's a problem.
There's really no way to typecheck this module as it is, because it is not
the real base:GHC.Prim. The real base:GHC.Prim is in GHC's belly, it has
no source code.
So the only way to get this past the compiler is to change its name. There
are two options: change the package name, or change the module name.
Probably the latter is easier, because otherwise you'd have to make a
separate package (+Cabal bits) for this.
But then you have the problem that the docs are generated with the wrong
module name. So I guess the only way to fix this is to tell Haddock
somehow that it has to change the module name back to GHC.Prim after GHC
has typechecked it.
Cheers,
Simon
David Waern wrote:
Simon,
What do you think we should do here?
David
2007/11/23, David Waern <[EMAIL PROTECTED]>:
2007/11/17, Ian Lynagh <[EMAIL PROTECTED]>:
Hi David,
If I understand correctly, your patch
Fri Nov 9 00:08:06 GMT 2007 David Waern <[EMAIL PROTECTED]>
* Filter out GHC.Prim also for the Haddock step
Please merge to the GHC 6.8.2 branch
will remove GHC.Prim from the haddock docs, presumably because haddock 2
can't cope with it? However, the users guide points to it to document
the "Special built-in functions":
http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.html
and I think it's considered a module that users can import, so it ought
to be documented. Is it possible to make haddock 2 understand GHC.Prim
instead?
OK, so it's wrong to filter it out in the Haddock 0.x case.
In the Haddock 2 case I'm not sure what to do since it seems to be
impossible to typecheck this module with GHC. If Haddock 2 can't
typecheck a module it can't generate documentation for it.
David
_______________________________________________
Cvs-libraries mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-libraries
_______________________________________________
Cvs-libraries mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-libraries
