Request for comments on proposal for literate programming using markdown
ekmett at gmail.com
Tue Aug 21 14:47:44 CEST 2012
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.
On Tue, Aug 21, 2012 at 7:45 AM, Philip Holzenspies
<pkfh at 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 ;)
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users