- ghc-devs - Haskell.org

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

RFC re #10196 & GHC 7.10.2: Allow Unicode Lm category for 2nd+ character on in identifiers
by Herbert Valerio Riedel 06 May '15

06 May '15

Hello *, As you may be aware, GHC 7.10.1 updated its Unicode catalog to version 7.0, thereby causing some subscript symbols to change character properties, thereby causing GHC 7.10.1 to reject some Unicode-subscript characters that GHC 7.8.4 accepted. See https://ghc.haskell.org/trac/ghc/ticket/10196 for specific examples. In order to address this regression, one suggestion is to allow characters in the 'Letter, Modifier' category[1] from the 2nd position on in an identifier. This however may do more than just fix the regression, as it looks from [1] that it would allow many more new identifiers than were previously possible. So, is allowing 'Lm'-chars the the 2nd+ characters in an identifier a sensible change for addressing #10196 or not. If it's a bad idea, are there other suggestions worth considering? [1]: http://www.fileformat.info/info/unicode/category/Lm/list.htm Cheers, hvr

1 0

FW: [Haskell-cafe] Significant changes in -Wall for GHC 7.10
by Simon Peyton Jones 05 May '15

05 May '15

GHC devs, I wasn’t aware that we’d changed these. Anyone know why? Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Omari Norman Sent: 05 May 2015 15:55 To: haskell Cafe Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: -fwarn-type-defaults -fwarn-name-shadowing -fwarn-missing-signatures -fwarn-hi-shadowing -fwarn-orphans -fwarn-unused-do-bind -fwarn-trustworthy-safe I can't find any mention in the release notes of this change in behavior. I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse.

2 1

Annotation restriction is not respected while generating Annotation via TH
by magesh b 05 May '15

05 May '15

As per user guide one of the restriction in annotating value is . The binder being annotated must be declared in the current module But when I use TH to generate the annotation above restriction is not respected. Below is the minimal test case to reproduce the issue ---- Ann.hs {-# LANGUAGE TemplateHaskell #-} module Ann where import Language.Haskell.TH -- {-# Ann id "Orphan Ann for id" #-} -- *Rightly produces error "Not in scope: ‘id’"* $(pragAnnD (ValueAnnotation 'id) [|"Orphan Ann for id"|] >>= return . return) --* Ideally this should have produced same error as above* ---- End of Ann.hs ---- Main.hs {-# LANGUAGE TemplateHaskell #-} module Main where import Ann () import Language.Haskell.TH ann :: [String] ann = $((reifyAnnotations (AnnLookupName 'id) :: Q [String]) >>= (\anns -> [|anns|])) --err = 'a' && True -- Uncomment to introduce compile error main :: IO () main = print ann ---- End of Main.hs Also there is another bug in reifying the Orphan Annotations. In the above example Main.hs depends on Ann.hs which defines Annotation for `id` When Main.hs compiles fine in the first go, its is able to retrieve the annotation for `id` Instead, if Ann.hs compiled successfully and Main.hs failed to compile and when you later fix the Main.hs error, it is not able to retrieve that annotation without recompiling Ann.hs Regards, Magesh B

2 2