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

Quoth wren romano
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.
But fatal if compilation is conditional on something that affects the ability to type check, am I right? Such as different compilers or versions of same compiler. Donn

On Fri, May 8, 2015 at 7:40 PM, Donn Cave
But fatal if compilation is conditional on something that affects the ability to type check, am I right? Such as different compilers or versions of same compiler.
Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Fri, May 8, 2015 at 7:56 PM, Brandon Allbery
On Fri, May 8, 2015 at 7:40 PM, Donn Cave
wrote: But fatal if compilation is conditional on something that affects the ability to type check, am I right? Such as different compilers or versions of same compiler.
Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals.
There's also the question about handling changes in syntax, e.g. LambdaCase throws parse errors in older compilers. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

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 (5)
-
Brandon Allbery
-
Dan Doel
-
Daniel Trstenjak
-
Donn Cave
-
wren romano