Ultimately your best bet to actually get something integrated will be to find something that minimizes the amount of work on the part of GHC HQ. <div><br></div><div>I don't think <i>anybody</i> there is interested in picking up a lot of fiddly formatting logic and carving it into stone.<div>
<br></div><div>They might be slightly less inclined to shut the door in your face if the proposal only involved adding a few hooks in the AST for exposing alternative documentation formats, which would enable you to hook in via a custom unlit or do something like how haddock hooks in, but overall, if it involves folks at GHC HQ maintaining a full markdown parser I think they will (and should) just shrug and move on.</div>
<div><br></div><div>The resulting system would be slightly less work for you, but would only see any improvements delayed a year between GHC releases, and then the community can't adopt the improvements in earnest for another year after that. This is <i>not</i> an encouraging development cycle, and doesn't strike me as a recipe for a successful project. </div>
<div><br></div><div>As proposed, this would distract some pretty core resources from working on core functionality and I for one am heavily against it as I understand what has been proposed so far. </div><div><br></div><div>
Haddock works with some fairly simple extensions to GHC's syntax tree. If your proposal was modified so that it just requires a few hooks or worked with the existing haddock hooks in the syntax tree, then while I would hardly be a huge proponent due the fragmentation issues about how to deal with documentation, I would at least cease to be actively opposed.</div>
<div><br></div><div>-Edward</div><div><br></div><div><div class="gmail_quote">On Tue, Aug 21, 2012 at 7:45 AM, Philip Holzenspies <span dir="ltr"><<a href="mailto:pkfh@st-andrews.ac.uk" target="_blank">pkfh@st-andrews.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 14 Aug 2012, at 07:48, Simon Hengel wrote:<br>
> Personally, still do not see the big benefit for all that work, and I'm<br>
> still somewhat worried that a mechanism that is not used by default (I'm<br>
> talking about unliting with an external command) may start to bit rot.<br>
> But as long as you are commit to keep `-pgmL` intact, I'm ok ;).<br>
<br>
</div>A biggy that I had left out has just reoccurred to me. The very first reason for me to look at how unlitting and preprocessing is done in GHC was, because I was looking into what would be required for a refactoring engine (like haRe) to be based on the GHC API. Of course, at the moment, the API doesn't do anything with unlitting and preprocessing.<br>
<div class="im"><br>
> I think in the end it's best to go with the solution that works best for<br>
> GHC-HQ.<br>
<br>
</div>Still hoping to hear from them ;)<br>
<br>
Regards,<br>
Philip<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br></div></div>