- ghc-devs - Haskell.org

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

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

RE: Generalized Newtype Deriving not allowed in Safe Haskell
by Simon Peyton Jones 30 Apr '15

30 Apr '15

There is a long discussion on https://ghc.haskell.org/trac/ghc/ticket/8827 about whether the new Coercible story makes GND ok for Safe Haskell. At a type-soundness level, definitely yes. But there are other less-clear-cut issues like “breaking abstractions” to consider. The decision on the ticket (comment:36) seems to be: GND stays out of Safe Haskell for now, but there is room for a better proposal. I don’t have an opinion myself. David Terei and David Mazieres are in the driving seat, but I’m sure they’ll be responsive to user input. However, I think the user manual may not have kept up with #8827. The sentence “GeneralizedNewtypeDeriving — It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.” vanished from the 7.8 user manual (links below). Maybe it should be restored. Safe Haskell aficionados, would you like to offer a patch for the manual? And maybe also a less drastic remedy than omitting GND altogether? Simon From: Omari Norman [mailto:omari@smileystation.com] Sent: 09 April 2015 02:44 To: haskell Cafe Subject: Generalized Newtype Deriving not allowed in Safe Haskell When compiling code with Generalized Newtype Deriving and the -fwarn-unsafe flag, I get -XGeneralizedNewtypeDeriving is not allowed in Safe Haskell This happens both in GHC 7.8 and GHC 7.10. I thought I remembered reading somewhere that GNTD is now part of the safe language? The GHC manual used to state that GNTD is not allowed in Safe Haskell: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe-haskell… But this language on GNTD not being part of the safe language was removed in the 7.8 manual: https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe-haskell… The GHC release notes don't say anything about this one way or the other. Thoughts?

3 9

Roles, GND, Data.Coerce
by David Terei 30 Apr '15

30 Apr '15

All, An issue that came up with GHC 7.8 was the design of Roles and Data.Coerce, with it's ability to break module abstractions by default, requiring programmers adopt explicit role annotations to enforce some types of invariants for abstract data types. Because of this issue, as of now, GND & Data.Coerce are still disabled in Safe Haskell. We'd like to change this but need feedback from everyone. I've written up a wiki page with lots of information on the issue: https://ghc.haskell.org/trac/ghc/wiki/SafeRoles Please read, it has information on how Roles work, the problem it raises and subtleties in the current system. Possible paths forward are also there, but I'll include below. Please be aware that this discussion is about Roles in general, not specifically how when using -XSafe. Ideally we'd come up with a solution that works regardless of if using Safe Haskell or not. I personally like option (3), although it isn't clear to me how hairy the implementation would be. == Possible Paths Forward for Roles == 1) Do Nothing -- Keep Roles & GND unchanged, keep them unsafe in Safe Haskell. 2) Accept as Safe -- Keep Roles & GND unchanged, accept them as safe in Safe Haskell and warn users that they neednominal role annotations on ADTs. 3) In-scope constructor restriction for lifting instances -- The newtype constructor restriction for unwrapping instances could be extended to both data types, and the lifting instances of Data.Coerce. This is, GND & Coercing under a type constructor is allowed if (a) all involved constructors are in scope, or (b) the constructors involved have been explicitly declared to allow coercion without them being in scope. I.e., (b) allows library authors to opt-into the current GHC behavior. This would require new syntax, probably just an explicit deriving Coercible statement. 4) Change default role to nominal -- This will prioritize safety over GND, and the belief is that it may break a lot of code. Worse, that it will be an ongoing tax as role annotations will be needed to enable GND. 5) Nominal default when constructors aren't exported -- When a module doesn't export all the constructors of a data type, then the type parameters of the data type should default to nominal. This heuristic seems to capture somewhat the intention of the user, but given the practice of defining an Internal module that exports everything, it seems of limited use. 6) Nominal default in future -- Add a new extension, SafeNewtypeDeriving that switches the default role to nominal, but continue to provide a deprecated GND extension to help with the transition. The claims in support of representational roles as default though believe that nominal by default has an ongoing, continuous tax, not just a transition cost. So it isn't clear that any scheme like this satisfies that argument. 7) Safe Haskell Specific -- Many of the above approaches could be adopted in a Safe Haskell specific manner. This isn't ideal as it makes safe-inference harder and Safe Haskell less likely to remain viable going forward. Richard suggests one such idea. == The belief by many people seems to be that (4) and (6) would be too much of burden. I'd like to avoid (7) if possible. It isn't clear to me if (7) ends up better than (2). I'm going to try to setup some infastructure for compiling Hackage so that we can measure how impactful these changes would be. Cheers, David

1 0

RE: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr from local calls
by Simon Peyton Jones 30 Apr '15

30 Apr '15

Thanks! I've added a comment to the relevant Note to document the effect. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 30 April 2015 08:10 | To: Simon Peyton Jones | Subject: [Diffusion] [Commented On] rGHCb61562feb876: Seed SpecConstr | from local calls | | nomeata added a subscriber: nomeata. | nomeata added a comment. | | Nice: -4% alloc in nofib/multiplier, -2.8% in nofib/minimax. 👍 | | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb61562feb876 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC | Cc: nomeata

1 0