Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
vector generates a considerable amount of code using CPP macros.
And with regard to other mails, I'm not too eager (personally) to port that
to template Haskell, even though I'm no fan of CPP. The code generation
being done is so dumb that CPP is pretty much perfect for it, and TH would
probably just be more work (and it's certainly more work to write it again
now that it's already written).
On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson
On 06-05-2015 15:05, Alan & Kim Zimmerman wrote:
Perhaps it makes sense to scan hackage to find all the different CPP idioms that are actually used in Haskell code, if it is a small/well-defined set it may be worth writing a simple custom preprocessor.
+1, I'll wager that the vast majority of usages are just for version range checks.
If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication.
Regards,
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
On Fri, May 8, 2015 at 12:12 PM, Dan Doel
vector generates a considerable amount of code using CPP macros.
And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written).
Incidentally, if we really want to pursue the "get rid of CPP by building it into the GHC distro"... In recent years there've been a number of papers on "variational lambda-calculi"[1] which essentially serve to embed flag-based preprocessor conditionals directly into the language itself. One major benefit of this approach is that the compiler can then typecheck *all* variations of the code, rather than only checking whichever particular variation we happen to be compiling at the time. This is extremely useful for avoiding bitrot in the preprocessor conditionals. ...If we were to try and obviate the dependency on CPP, variational typing seems like a far more solid approach than simply reinventing the preprocessing wheel yet again. (The downside, of course, is making the Haskell spec significantly more complex.) [1] e.g., http://dl.acm.org/citation.cfm?doid=2398856.2364535 -- Live well, ~wren
Hi Wren,
Incidentally, if we really want to pursue the "get rid of CPP by building it into the GHC distro"...
In recent years there've been a number of papers on "variational lambda-calculi"[1] which essentially serve to embed flag-based preprocessor conditionals directly into the language itself. One major benefit of this approach is that the compiler can then typecheck *all* variations of the code, rather than only checking whichever particular variation we happen to be compiling at the time. This is extremely useful for avoiding bitrot in the preprocessor conditionals.
...If we were to try and obviate the dependency on CPP, variational typing seems like a far more solid approach than simply reinventing the preprocessing wheel yet again. (The downside, of course, is making the Haskell spec significantly more complex.)
I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel
participants (3)
-
Dan Doel -
Daniel Trstenjak -
wren romano