On Thu, 2008-12-11 at 23:32 +0100, Sean Leather wrote:
> That's quite a presumption there. I can certainly write a module that > compiles and produces documentation for Haddock but that is different > when compiled into binary form. Even without this particular problem, > I can see that being potentially useful.
Sure, but it'd have to be a different cpp flag because the existing one is used for a different purpose.
But what purpose does __HADDOCK__ serve if not to inform a file of code that haddock is currently processing it?
To inform a file that haddock-0.x is currently processing it.
Perhaps even better would be a __HADDOCK_VERSION__ definition that allows for code to work through changes in the tool.
Yes, and files would have to actually test that version number. That's why we cannot just do -D__HADDOCK__=2, because existing modules just do: #ifdef __HADDOCK__ which means they would present broken code to haddock-2.
While CPP may not be the most type-safe tool in the world and definitely not ideal for text macro substitution, it does do this simple kind of job very well.
Sure. Let's see what David thinks. If he thinks is possible to fix these kinds of things where haddock is not covering the whole GHC AST (at least to the degree where it can ignore bits it does not understand). If that's not realistic in the short term then we probably should introduce some haddock version macro so that people can workaround it. Duncan