I guess there was some confusion about the haddock-as-preprocessor idea.&nbsp; Here&#39;s another try:<br><br>Pare the Haddock markup language down to very few markup directives, say just &#39;foo&#39; and &quot;Foo.Bar&quot;.&nbsp; (Of course, Haddock continues to read and process type signatures and module import &amp; export specs.)&nbsp; Compose this slimmed down Haddock with a more mainstream and powerful markup language/processor like markdown/pandoc.&nbsp; How to compose?&nbsp; By having Haddock translate its markdown extensions into markdown and pass through all the rest.<br>
<br>The goal redesigning for composability is that we get more for less.&nbsp; Haddock can focus on its speciality, namely hyperlinked Haskell code documentation, and pandoc on its, namely human-writable and -readable prose with modern features (images, friendly hyperlinks, smart quotes &amp; dashes, footnotes, super- and subscripts, pretty math, bibliography-style link specs, etc).&nbsp; Haddock development can focus its resources on Haskell-specific functionality, and we library writers can still use a full-featured mark-up language.<br>
<br>I love Haddock&#39;s Haskell-smarts, and I love (extended) markdown&#39;s features and usability.&nbsp; Currently, I have to choose between them, and I&#39;d rather get both at once.<br><br>We can take this composability idea further and plug in other nifty tools like hscolour and lhs2TeX.&nbsp; And a new tool that hyperlinks and annotates source code in a variety of ways.&nbsp; For instance, hover over an identifier to see its type and doc string in a pop-up, or click to jump to the source code (also annotated with type, doc, and source links).&nbsp; And other tools we haven&#39;t yet thought of.<br>
<br>Cheers,&nbsp; - Conal<br><br><br><div class="gmail_quote">On Thu, Feb 21, 2008 at 5:12 AM, Alistair Bayley &lt;<a href="mailto:alistair@abayley.org" target="_blank">alistair@abayley.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>On 21/02/2008, Duncan Coutts &lt;<a href="mailto:duncan.coutts@worc.ox.ac.uk" target="_blank">duncan.coutts@worc.ox.ac.uk</a>&gt; wrote:<br>
&gt;<br>
&gt; To be honest I like the fact that haddock&#39;s markup is really simple and<br>
&gt; &nbsp;perhaps somewhat restrictive. A great improvement though would be to<br>
&gt; &nbsp;make it easy to extract the docs from haddock in a nice format so that<br>
&gt; &nbsp;the could be re-used in other contexts rather than just generating html<br>
&gt; &nbsp;api documentation. Haddock does have support for multiple backends,<br>
&gt; &nbsp;someone just needs to define and write a generic backend that spits out<br>
&gt; &nbsp;the info that haddock gathers in a machine readable format.<br>
<br>
</div>I have probably misunderstood both of you, but I think that Conal<br>
proposed that Haddock *input* syntax is largely unchanged; Haddock<br>
should be able to *output* markdown, for consumption by pandoc.<br>
<br>
(Which I think is also what you&#39;re suggesting.)<br>
<font color="#888888"><br>
Alistair<br>
</font></blockquote></div><br>