Would it be possible to add something like
{-# LANGUAGE CPP #-}
#if defined(__GLASGOW_HASKELL__) __GLASGOW_HASKELL__ = 704
{-# LANGUAGE PolyKinds #-}
#endif
to the top of Control.Category before the 7.6.1 final release?
Control.Category.Category is pretty much the only type in base that
On 9 Aug 2012, at 15:26, Simon Hengel wrote:
Just to clarify, I was not talking about pandoc, but pandoc-unlit (which
uses pandoc to unlit Markdown, see the README [1]).
Sorry, I was a bit unclear there. I know about the program and it depends on
the library.
However, it's a bit of an
On Mon, Aug 13, 2012 at 08:45:51AM +, Philip Holzenspies wrote:
However, it's a bit of an overspec'd package to link into the
compiler, don't you think?
I did not mean to modify the Compiler. Unliting is done by an
external program. This already allows you to customize unliting
Dear Simon,
On 13 Aug 2012, at 10:23, Simon Hengel wrote:
I think it makes sense, that you do not want to depend on pandoc for
GHC's build process. But would a more lightweight unlit for Markdown
work?
Ultimately, all unlitting does is replace things not in code blocks by white
lines.
On Mon, Aug 13, 2012 at 11:02:59AM +, Philip Holzenspies wrote:
My proposal, however, is to replace the external unlit
..
by code *inside* GHC.
What is the benefit of doing so?
Cheers,
Simon
___
Glasgow-haskell-users mailing list
On 13 Aug 2012, at 13:20, Simon Hengel wrote:
What is the benefit of doing so?
- Simpler build environment
- Easier to understand interaction and bugs resulting from them (viz. [1],
[2]), because the interactions happen in the same domain
- (as mentioned in the proposal) Simplification of the
Control.Category.Category is pretty much the only type in base that
directly benefits from PolyKinds without any code changes, but without
enabling the extension there nobody can define categories for kinds other
than *, and most interesting categories actually have more exotic kinds.
What,
On Mon, Aug 13, 2012 at 9:55 AM, Dan Burton danburton.em...@gmail.comwrote:
Control.Category.Category is pretty much the only type in base that
directly benefits from PolyKinds without any code changes, but without
enabling the extension there nobody can define categories for kinds other
than
Hi Philip,
On Mon, Aug 13, 2012 at 12:57:44PM +, Philip Holzenspies wrote:
What is the benefit of doing so?
- Simpler build environment
- Easier to understand interaction and bugs resulting from them (viz.
[1], [2]), because the interactions happen in the same domain
- (as
Dear Simon,
On 13 Aug 2012, at 15:18, Simon Hengel wrote:
Thanks a lot for the clarification.
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
10 matches
Mail list logo