May 2015 - ghc-devs - Haskell.org

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

Hoopl question
by Michal Terepeta 05 May '15

05 May '15

Hi, I've just read through the Hoopl paper and then noticed https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance which is really interesting. But it seems that there were no updates to the page in like 3 years, yet the new codegen seems to be using Hoopl... Does anyone know what is the current status of this? Thanks, Michal

4 7

Help with GHC 7.10 on Homebrew?
by Mike Craig 04 May '15

04 May '15

Hey all, I'm trying to help improve the GHC-via-Homebrew situation. It's been busted for a while now. Someone opened a reasonable-looking PR to update the ghc formula. It removes a few bad hacks added over the years: https://github.com/Homebrew/homebrew/pull/39134 However, the build fails on CI when setting up HPC: > cat utils/hpc/hpc.wrapper >> inplace/bin/hpc > cat: utils/hpc/hpc.wrapper: No such file or directory The full log is here, with that error near the bottom: http://bot.brew.sh/job/Homebrew%20Pull%20Requests/25284/version=yosemite/te… Is this problem familiar to anyone? That formula builds on my laptop (also Yosemite), and I'm not familiar enough with the GHC build to know what to try next. Any help is much-appreciated! Mike

1 0