<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>
<div>On 21 Aug 2012, at 13:47, Edward Kmett wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">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. </blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Check.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<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>
<div>
<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>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<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>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<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>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Ph.</div>
</div>
</body>
</html>