Request for comments on proposal for literate programming using markdown
sol at typeful.net
Tue Aug 14 08:48:15 CEST 2012
On Mon, Aug 13, 2012 at 03:20:53PM +0000, Philip Holzenspies wrote:
> > I see some value in your proposal to replace GHC's unlit, mainly in
> > terms of setting a common standard. Personally, I'd still feel more
> > comfortable if that proposed standard would be developed as a Hackage
> > package, so that it can proof itself useful first. I'm less convinced,
> > that it should be inlined into GHC (I do agree, that this would be
> > necessary, if you want to include the markdown into the AST. But where
> > is the user? HsSyn does not even use the GHC API, AFAIK.).
> HsSyn doesn't use the GHC API, but the GHC API uses HsSyn. If things
> aren't kept in the HsSyn, the API can not produce them either.
> Comments that the parser discards, the API can not produce.
Oh, I meant HsColour instead of HsSyn. Sorry for that.
> >> Would there be a benefit to *not* doing this other than *me* not
> >> having to do the work?
> > Yes, currently you can replace the unlit phase. So you can use
> > arbitrary markup in .lhs files. Which I think is quite useful.
> Just so that there are no misunderstandings: The proposal **never**
> suggested throwing out any pluggability for custom unlitters. I can
> not be clear enough about this. The **only** thing I intend to change
> is the **default** case of unlitting (and maybe CPP). **Whatever**
> options exist now (command line or otherwise) for using alternatives
> to the default cases will **remain** as they are.
> I don't think I ever suggested otherwise, so I'm surprised that this
> came up. Thanks for bringing it up, though, because if anyone else got
> that idea, I hope it is now thoroughly squashed!
> Having put this behind us, do you still see reasons not to do this?
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 ;).
I think in the end it's best to go with the solution that works best for
More information about the Glasgow-haskell-users