<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 6, 2014 at 3:33 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">


<div>On Mon, Jan 6, 2014 at 5:27 AM, Malcolm Wallace <span dir="ltr"><<a href="mailto:malcolm.wallace@me.com" target="_blank">malcolm.wallace@me.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div><span style="color:rgb(34,34,34)">I think the fundamental problem is that Haddock is now built on top of ghc.  So if a package cannot be built by ghc (for whatever reason, e.g. missing C library dependency), then it cannot be documented either.  This is a good deal less than useful.  A documentation generator ought to do a reasonable job, even if the code it is looking at is technically not-compilable.</span><br>



</div>
<br>
At work, we have a stand-alone documentation generator for Haskell, which requires no compiler.  Haddock also was once stand-alone.  I think it might be time to wind the clock backwards and retrieve this desirable property.<br>



</blockquote><div><br></div></div><div>The problem with that was you didn't get documentation if you used any GHC extension added within the past year or so. You can't win....</div></div></div></div></blockquote>


<div><br></div><div>This problem keeps popping up in our various tooling efforts so I thought it'd be worth pointing out that the general problem has been discussed in a paper.</div><div><br></div><div>Martin Odersky touched on the more general problem of trying to have two</div>

<div><br></div><div> * complete (e.g. supporting all extensions in our case) and</div><div> * identically behaving</div><div>
<br></div><div>implementations of the same compiler (or part of a compiler in our case) in the Scalable Component Abstractions paper [1]. It is very difficult and requires a huge amount of work. The Scala solution is the cake pattern which lets the Scala compiler expose itself as two different APIs, used for two different purposes (in their case the compiler proper and a reflection API).</div>

<div><br></div><div>Even if relying on the GHC API is a bit of a pain, it's better than relying on a subtly different implementation that supports some subset of the features.</div>
<div><br></div><div>1. <a href="http://lampwww.epfl.ch/~odersky/papers/ScalableComponent.pdf" target="_blank">http://lampwww.epfl.ch/~odersky/papers/ScalableComponent.pdf</a> </div><div><br></div></div></div></div>