On 21 Aug 2012, at 13:47, Edward Kmett wrote: 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.
Check. 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. I'm cursed with a very suggestive writing style. I have no idea why Simon got the idea I wanted to remove the command line arguments. I have no idea why you think I want to build full markdown parsers. Help me out; where did you get that idea? Also, just for the record, I'm planning on dealing with markdown as extensively as the current unlitter deals with LaTeX. 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. So, there are many things people read in the proposal that I didn't want to put in, but the things I very much do want to include get lost in translation also. I wanted to allow the GHC source itself to be written in markdown. 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. I thought that GHC first runs unlit, then CPP and only then does it construct an AST. I don't know how to implement unlitting by hooks in the AST, if unlitting happens before building the AST. Unfortunately, it seems the proposal is so poorly written that I've spent more time dealing with the misconceptions it creates than actually implementing the unlitter. I'll retract the proposal. Ph.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
