I don't think
anybody there is interested in picking up a lot of fiddly formatting logic and carving it into stone.
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.
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 not an encouraging development cycle, and doesn't strike me as a recipe for a successful project.
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.
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.
-Edward
On Tue, Aug 21, 2012 at 7:45 AM, Philip Holzenspies
<pkfh@st-andrews.ac.uk> wrote:
On 14 Aug 2012, at 07:48, Simon Hengel wrote:
> Personally, still do not see the big benefit for all that work, and I'm
> still somewhat worried that a mechanism that is not used by default (I'm
> talking about unliting with an external command) may start to bit rot.
> But as long as you are commit to keep `-pgmL` intact, I'm ok ;).
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.
> I think in the end it's best to go with the solution that works best for
> GHC-HQ.
Still hoping to hear from them ;)
Regards,
Philip