May 2015 - ghc-devs - Haskell.org

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

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Sven Panne 06 May '15

06 May '15

2015-05-06 16:21 GMT+02:00 Bardur Arantsson <spam(a)scientician.net>: > +1, I'll wager that the vast majority of usages are just for version > range checks. The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. > 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. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588.

4 4

Tracking bugs for libraries
by Jan Stolarek 06 May '15

06 May '15

I just noticed that bugs for several of our libraries can either be tracked on Trac (there is a corresponding entry in the "Component" field) or on github (issue tracking for that library is enabled in the repo). These libraries are: directory, hoopl, old-time, pretty, process, random and unix. I don't like the idea of spreading bug reports in two separate places, unless there is a good reason for doing this (eg. because we actually use our own copies of these libraries). So, is this duplication intended or accidental? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 4