I'd like to point out that cpphs is a thing.  And that the near term plans for ghc are likely to lean on cpphs. <div><br></div><div>A huge constraint is that ghc and many other Haskell code bases use cpp, and unless we migrate everything any near term choice will essentially be a Haskell aware cpp.  <span></span><br>
<br>On Wednesday, April 16, 2014, Mike Meyer <<a href="mailto:mwm@mired.org">mwm@mired.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
On Apr 16, 2014 5:35 AM, "Ben Franksen" <<a href="javascript:_e(%7B%7D,'cvml','ben.franksen@online.de');" target="_blank">ben.franksen@online.de</a>> wrote:<br>
> Furthermore, I strongly suggest that a suitable replacement for CPP should<br>
> be designed in such a way that its specification can be added to a future<br>
> Haskell language standard. This is the only way to ensure that<br>
> implementations other than GHC can be brought along.</p>
<p dir="ltr">Do we need a Haskell-specific language preprocessor, or just one that's designed to be a general purpose preprocessor instead of specific to some language that's not Haskell? For instance, m4 should be available on most Unix-like systems, and wouldn't have most of the problems I've seen mentioned here. Not allowing single quotes in its variable names would still happen, but those should be lexically distinct from Haskell variables.</p>


</blockquote></div>