- ghc-devs - Haskell.org

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Daniel Trstenjak 11 May '15

11 May '15

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

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 09 May '15

09 May '15

On Fri, May 8, 2015 at 7:40 PM, Donn Cave <donn(a)avvanta.com> 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. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 1

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Dan Doel 08 May '15

08 May '15

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 <spam(a)scientician.net> wrote: > 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(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 08 May '15

08 May '15

On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm

7 9

RE: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler
by Simon Peyton Jones 08 May '15

08 May '15

Edward (Yang) I'm on a train so can't say this on Trac. I'm OK with enabling quotes (*not* quasiquotes) in stage1. Both typed and untyped quotes should work, correct? I'd rather it was done by using TemplateHaskell, and complaining if you use splices or quasi-quotes in stage1. (That is very much what happens now.) No new flags. Could the user manual briefly mention this? (Briefly because most users won't even know what a stage1 compiler is.) Could you add a Note somewhere appropriate to explain this? Perhaps mention the ticket, because Edward K's motivation is useful. Refer to the Note anywhere appropriate. Go for it. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 05 May 2015 16:06 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10382: Template Haskell (non-quasi) quotes should | work with stage 1 compiler | | #10382: Template Haskell (non-quasi) quotes should work with stage 1 | compiler | -------------------------------------+----------------------------------- | -- | Reporter: ezyang | Owner: ezyang | Type: feature request | Status: new | Priority: normal | Milestone: 7.12.1 | Component: Template Haskell | Version: 7.11 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | Blocked By: | Test Case: | Related Tickets: | Blocking: | | Differential Revisions: | Phab:D876 | -------------------------------------+----------------------------------- | -- | | Comment (by ekmett): | | The current situation: | | On one hand I have a number of packages that provide `TemplateHaskell` | convenience functions for users, `lens` being the go-to example. But on | the other hand, I have a bunch of folks who maintain releases for my | packages on platforms where only a stage1 compiler is available, Joachim | Breitner and the Debian folks used to maintain patches and versions of | my | code that removed large chunks of the libraries to build on those | platforms. | | When i found out, I offered to support stage1 compilers myself more | directly. This ensured a more uniform API, and that different | distributions weren't crippling my code in different ways, making it so | certain combinators or modules just weren't available on certain | platforms. | | But then we ran into an issue, we needed to generate names that linked | to | the right places within our code. So we manually construct all of our | names ourselves, using the cabal-supplied version number or package key | when needed: | | | https://github.com/ekmett/lens/blob/9a247b52ed20e578d9c843d8cc6dad5433a1c | 186/src/Control/Lens/Internal/TH.hs#L104 | | Then we just don't use the TemplateHaskell extension ourselves, despite | linking against the `template-haskell` package and everything is good | enough for us to limp along. | | I would love to eventually be able to drop this set of hoops, but I have | few opinions on the best way to get there. That said, Edward's | suggestion | of making TemplateHaskell just bomb when you reach a splice site in | stage1 | rather than immediately would avoid introducing any new flags and sounds | pretty simple. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10382#comment:6> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

1 0

HCAR DUE SOON: Please help edit!
by Austin Seipp 08 May '15

08 May '15

Hi *, (Apologies for the caps lock cruise-control in the title.) After sitting on it for a bit, it dawned on me today that the may HCAR report is due soon - in about two weeks! So, it's that time of the year again, and I'd like you all to take a quick glance at the page and edit some stuff in about what you're all working on, because I can't possibly keep up with it all. :) https://ghc.haskell.org/trac/ghc/wiki/Status/May15 Note that I've already put some boilerplate on the page, but some of it is old, from the last report - but some other things slipped, so maybe it's not old! The best case is you will read this page in 5 minutes and it will look OK. At worst, you may need to tweak a paragraph or write a new one - so please read and contribute! Note: I'll continue editing this page as time goes on, to prepare it for submission. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 6

release timing
by Mark Lentczner 08 May '15

08 May '15

I'm wondering if ghc 7.10.2 has a rough time table yet? This time 'round I'd like to do a HP 7.10.2 concurrent with GHC 7.10.2! Crazy, I know, and who knows if we can pull it off.... But I imagine it is about 3 or 4 week cycle for HP at this point (still)... so a few weeks' "heads up" would be good. Thoughts? - Mark

9 14

release timing
by Randy Polen 07 May '15

07 May '15

For the sake of the Haskell Platform users, I hope 7.10.2 will include the following fixes in the accompanying haddock and cabal. * Support for haddock response files to handle very long command lines (Windows) * https://github.com/haskell/cabal/pull/2512 * https://github.com/haskell/cabal/issues/1681 * https://github.com/haskell/haddock/issues/285 * https://github.com/haskell/haddock/issues/379 * Correct the cross-package links for all haddock-generated documentation (All) * https://github.com/haskell/haddock/issues/385 * https://ghc.haskell.org/trac/ghc/ticket/10206 The shenanigans I did to get the Windows HP built using a hacked up cabal and haddock were not appropriate for a release (and so I never released my builds of the HP 2015.2.0.0 on the Windows platform). On top of that, once I finally got it all to build in this uncomfortable, un-reproducible way (e.g., hacked PATH to hacked binaries), I noticed all the cross-package and index links in the docs were wrong, which sealed the deal (as far as I was concerned) to not release it. I hope that the solutions to these two issues can be incorporated into 7.10.2, so that build process for the Windows HP will be worthy and suitable for such a release, and so that the documentation links will be correct and useful to the users. Randy

1 0

Re: release timing
by Harry . 07 May '15

07 May '15

#10293 should go in as it's a (significant?) regression. It would be nice to see #8224 in as well, but doesn't look like that's going to be fixed any time soon! Have GHC HQ ever considered asking Intel if they'd be willing to lend a hand?

2 2

FW: release timing
by Simon Peyton Jones 07 May '15

07 May '15

ccing ghc-devs From: David Fox [mailto:dsf@seereason.com] Sent: 07 May 2015 03:09 To: Simon Peyton Jones Subject: Re: release timing Drat, wrong "reply to"! On Wed, May 6, 2015 at 7:08 PM, David Fox <dsf(a)seereason.com<mailto:dsf@seereason.com>> wrote: On Wed, May 6, 2015 at 2:58 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Mark Good points but: • If literally no one actually finds the absence of 7.10.2 a problem, we could save a lot of work (for you) by not releasing it! I think it’s reasonable to have some evidence of need before investing the effort (for both GHC and HP) needed for a release.• There are fixes in 7.10.2 that are important to ghcjs.

1 0