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.
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 <p...@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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users