[Haskell-cafe] Problem with haddock 2.3.0 (again)

[Duncan Coutts]

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