October 2015 - ghc-devs

Show instances for GHC internals
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

Currently the only way to debug and inspect GHC internals is by adding some carefully placed print statements. (I'd love to be proven wrong on this, cost of debugging this way is huge, given how long it's taking to rebuild GHC) We have Outputable instances for most data types, and `Outputable.pprTrace` etc. helps with debugging/inspecting pure functions this way. However, Outputable instances are hiding some details and they're sometimes not useful for debugging and inspecting internals. This is why I implemented CoreDump package(http://hackage.haskell.org/package/CoreDump), Outputable instance of CoreSyn is simply not useful for some things. Similarly, just today I had to add a show function for `HscTypes.TargetId` because `Outputable` instance was hiding `Maybe Phase` field. Since the only way to debug or inspect GHC internals(except maybe the RTS) is by printing things, I think we should provide Show instances for.. basically everything. Otherwise I just can't see a way of debugging things and inspecting internals, tracing code etc. for learning purposes. I was wondering what would be the cost of adding Show instances. Would that mean significantly increased compile times? Or significantly bigger GHC binaries? If that's the case, could we enable Show instances with some arguments so that we can enable/disable it by modifying mk/build.mk?

4 6

Taking a step back
by Johan Tibell 20 Oct '15

20 Oct '15

Friends, I'm taking a step back from day-to-day library work. There are two main reasons I use Haskell: on one hand I find writing Haskell educational and fun. On the other I hope to make it a viable alternative to existing mainstream languages. With recent changes to our core libraries, and the general direction these are moving in, I believe we're moving away from becoming a viable alternative to those mainstream languages. This has some practical implications for how I spend my Haskell hacking time. Much of what I do is maintaining and working on libraries that are needed for real world usage, but that aren't that interesting to work on. I've lost the motivation to work on these. I've decided to take a step back from the core maintenance work on cabal, network, containers, and a few others* starting now. I've already found replacement maintainers for these. I still plan to hack on random side projects, including GHC, and to continue coming to Haskell events and conference, just with a shorter bug backlog to worry about. :) -- Johan Tibell * For now I will still hack on unordered-containers and ekg, as there are some things I'd like to experiment with there.

4 3

is this change in TH error message intentional?
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

Hi all, I realized this change in TH error messages: GHC 7.10.2: ➜ th-test ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: Not in scope: ‘locaton’ Perhaps you meant ‘location’ (imported from Language.Haskell.TH.Syntax) In the splice: $locaton Main.hs:13:15: GHC stage restriction: ‘locaton’ is used in a top-level splice or annotation, and must be imported, not defined locally In the expression: locaton In the splice: $locaton I think both error messages are quite useful in this context. I don't see second one as redundant. However, with HEAD: ➜ th-test ghc-stage2 --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:13:15: error: Variable not in scope: locaton :: ExpQ Perhaps you meant ‘location’ (imported from Language.Haskell.TH.Syntax) I think this new message is quite worse than previous one. First, "In the splice ..." part is missing. Second, "It must be imported, not defined locally" message is not given at all. Was this change intentional? May I ask why it's changed?

3 3

Building stage1 only
by Ömer Sinan Ağacan 20 Oct '15

20 Oct '15

(I know I asked this many times in IRC channel but I don't remember getting any answers. I apologize if anyone had answered this on IRC channel and I missed) With current build system, even if I choose "devel1" it always builds stage2 compiler too. A comment in build.mk says that it's for working on stage1 compiler, so I'd expect it to build only stage1. The reason I want stage1-only builds is the time it takes to build both stages. It takes approximately 30 minutes and if I could reduce this down to half that would greatly improve my work flow. Most of the time I don't need a full build, but in my experience, it's very easy to end up in a state where `make` simply can't build, and only easy fix is a `make clean`, which costs 30 minutes because then I have to build from scratch. This happens way too often, and so I need a stage1-only build. Thanks..

4 5

Confusing error message when universally quantifying unused type variables
by Alexander Berntsen 20 Oct '15

20 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In Set theory sentence construction, if the letter is not used then no foul. In Haskell, it is not always so. The following is well-typed and works happily: f :: Eq a => b -> b f b = b However, this does not work: f :: ∀ a. Eq a => b -> b f b = b It will result in the error "Not in scope: type variable ‘b’" being spat out twice. Is this error message really desirable? If there is no principled reason for this result, may I suggest improving it? I can conceivably see some codebase using RankNTypes exclusively having a typo like f :: ∀ a. b -> b f b = b Consequently the error message should be more precise. Furthermore the first code snippet I gave also strikes me as nonsensical; if someone has code like that, it is probably the result of a typo. Should we really permit it? Is there a motivating reason for permitting it? If no, I suggest it be an error. (My understanding of the 2010 report was that it *isn't* permitted, but perhaps I read it wrong.) - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWJiE0AAoJENQqWdRUGk8BVmYP/0yhrfFs8LHLUAhGnza3f6Xx uFJQdvMmZcSLQQZxFyBvVcNwAK0x1ntnT+jeG/Q0j1oQns6EoWkJ9WzBQIxVQ2+O 9bm45N+gX1K1W1Z0WEX+LCPszntLMvBdp6C3Wp4ff+XvS9e0uHTqftDdD3iUexPA K5wTB5qs+3IWVFEyyPIuJpOqOLhTy9FMct9Ls4m72Uu3FIWPEgjANuT/WkkLASXP Av+qn0hTUzmoNf2nWcjvJQIZvgM6xfpJleWlO2CinOuPunZiackja/qTGlvx7Pu6 Yo5Fs2WdfCB1yx3iPnDcSrJ3pQcZkLqVsGRNdEXdQEHMH1icLR15Z7ynpKkI6uBb JI+vAyq//NbdbRUOPzwN/PA+kGczUTBhTeAnwB5194fdzlfmH9vDsdN8p4CPtsTG 3T3u5EEyn8a/v0nQPssDEfli8Mx4uOswQmTsLgJCJ1H94FbNdGS3R98NmM63A9II rN53o16m6z4C27YQL4q84LwbnWvOEyE9s3xBZMd8hsbTdb7F2syVoSYZazgP5PGc uv/pAwKqwkGU53yBBhj+RqfPXk3qf0bOHtsercIAhnmkIAjI5l7bdxmDyhW4aj49 pWRJgOPAAlQ+VriFoodMZ9PD42pvxUlzicDfvpELVpviHdlTrovky9UC+buCFrtG 7k9GmyHqe/B3LyDjxbh+ =jerq -----END PGP SIGNATURE-----

2 3

Moving forall with coerce
by David Feuer 20 Oct '15

20 Oct '15

It appears, as far as I can tell, that GHC can't move a forall past an -> with coerce. I was playing around with the MonadTrans instance for Codensity, wanting (essentially) to write lift = coerce (>>=) This is legal: instance MonadTrans Codensity where lift = frob frob :: forall m a . Monad m => m a -> Codensity m a frob = coerce (blah (Mag (>>=)) :: m a -> Mag2 m a) newtype Mag m a = Mag (forall b . m a -> (a -> m b) -> m b) newtype Mag2 m a = Mag2 (forall b . (a -> m b) -> m b) blah :: Mag m a -> m a -> Mag2 m a blah (Mag p) q = Mag2 (p q) The problem is that there doesn't *seem* to be a way to implement blah as a coercion. GHC doesn't recognize that Mag m a has the same representation as m a -> Mag2 m a The essential difference, as far as I can see, is that the `forall b` is shifted across `m a ->`. It seems that this really shouldn't be an issue, because 1. b is not free in `m a` 2. Type lambdas all compile away Would it be worth trying to extend the Coercible mechanism to deal with these kinds of situations? Or is there already some way to do it that I've missed? David

3 2

Unsubscribe
by dongen 20 Oct '15

20 Oct '15

Unsubscribe

1 0

GHC Weekly News - 2015/10/16
by Austin Seipp 16 Oct '15

16 Oct '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20151016) Hi *, Welcome for the latest entry in the GHC Weekly News, which has been somewhat irregularly scheduled - but we're as busy as ever! == 8.0.1 release roadmap == We're still steaming ahead on GHC 8.0.1 - any interested participants are suggested to look at the wiki:Status/GHC-8.0.1 page, to see where we're currently at. These past few weeks have been good: we've gotten the first part of the overloaded record fields work in, and we have plans to land the kind equalities work in November. Furthermore, Simon Marlow, Peter Wortmann and Ben are working on reviewing all of the DWARF improvements, and hopefully the start of this work will land next week. But 8.0 isn't the only thing that'll be getting released... == And some other minor releases == In a total, unprecedented upset - we're aiming to do ''three'' GHC releases in a fairly short amount of time. === 7.10.3 === Ben Gamari has been working on steadily hacking away at GHC 7.10.3, and the hopes are that we'll be able to ship it soon. This will fix several dozen bugs, some of which are critical for our users. You can keep up to date by following the wiki:Status/GHC-7.10.3 page. === 7.8.5 === Simultaneously, your author will ''also'' be working on a GHC 7.8.5 release. While we were alerted a few months ago to this breakage, it seems rather unfortunate for the 7.8 series to remain broken on such a popular OS. Furthermore, the "Three GHC Release Policy" for many authors - to support the last three major versions of GHC - would mean that 7.8 would be broken for OS X developers for an ''entire year until GHC 8.2.1''. Which is a pretty unfortunate circumstance. It's not expected the 7.8.5 release will contain any other fixes, however. == List chatter == (Over the past two weeks) - Ben Gamari wrote in about '''switching the users guide to reStructuredText''', and the TL;DR is - it's done! We'll have a beautiful new users guide for GHC 8.0.1 https://mail.haskell.org/pipermail/ghc-devs/2015-October/010029.html - Matthew Pickering comments about the state of pattern synonym signatures, remarking that they're currently confusing, noting down some things we could possibly fix. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010024.html - Ben Gamari talked about the status of the recent DWARF work, and so far it's looking good. The needed patches are still in the review pipeline, but the hope is that they'll all be done in time for 8.0.1. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010039.html - David A Roberts wrote in to ask a question: now that we have `ApplicativeDo`, what about `Applicative` comprehensions? The responses indicate this seems like it would be a great addition. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010062.html - Richard Eisenberg sent in a status update about his work on kind equalities, and the hope is it will land shortly in November! (Your editor then hassled him for a syntax change before landing.) https://mail.haskell.org/pipermail/ghc-devs/2015-October/010077.html - Adam Foltzer has requested another release of the GHC 7.8 series, due to it being completely broken on OS X El Capitan. Expect more news on this soon. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010078.html - Erik de Castro Lopo has recently been working with LLVM, and decided to publish his automation so interested GHC hackers could keep up to date and try new LLVMs easily. https://mail.haskell.org/pipermail/ghc-devs/2015-October/010086.html == Noteworthy commits == (Over the past two weeks) - Commit 4fd6207ec6960c429e6a1bcbe0282f625010f52a - Move the users guide to reStructured Text. - Commit 6cde981a8788b225819be28659caddc35b77972d - Make `GHC.Generics` capable of handling unboxed tuples. - Commit 0eb8fcd94b29ee9997b386e64203037bdf2aaa04 - Enable `Enumeration is empty` warnings for `Integer` - Commit 620fc6f909cd6e51b5613454097ec1c9f323839a - Make Windows linker more robust to unknown sections - Commit 5d841108acef950fed6a5e608ac9b18e7431aa87 - Add short library names support to the Windows linker - Commit f8fbf385b879fe177409a25cc9499275ea3dc45d - Reinstate monomorphism-restriction warnings - Commit dcc342870b4d8a739ccbed3ae26e84dcc3579914 - Don't inline/apply other rules when simplifying a rule RHS. - Commit dec5cd4085488686b5ed50bb26ccbc0ba7b645ec - base: Add `forkOSWithUnmask` - Commit e8c8173923302268ef950c3b21e276779e45ac83 - Allow arr ∧ (first ∨ (***)) as minimal definition of Arrow instance - Commit 29310b622801733e1b29a9a61988406872db13ca - Switch to LLVM version 3.7 - Commit 04e8366608fee4f5e3358acc855bc6f556c3f508 - ELF/x86_64: map object file sections separately into the low 2GB - Commit b1884b0e62f62e3c0859515c4137124ab0c9560e - Implement `DuplicateRecordFields` - Commit 75492e7467ff962f2f2e29e5c8b2c588c94ae8a7 - Add typed holes support in Template Haskell. - Commit 6a8ca65032c6b3ed61b5378765e70120083cf5da - Allow left ∨ (+++) as minimal definition of ArrowChoice instance == Closed tickets == (Over the past two weeks) #10392, #7883, #10475, #10745, #10926, #9238, #10700, #10810, #10342, #365(!), #10361, #10929, #10563, #9907, #10513, #10868, #10932, #8920, #10516, #10416, #5966, #8335, #10520, #10687, #10571, #9058, #10939, #10938, #9590, #10949, #10153, #10947, #10948, #10936, #1883, #5289, #10733, #10950, #10611, #10959, #10960, #10831, #10796, #10890, #8010, #10216, #10965, #10953, #10964, #10931, #10714, #10888, #10633, #8652, #3971, #10882, #10977, #10267, and #10911. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Request to reopen the issue of 7.8 on El Capitan
by Adam Foltzer 16 Oct '15

16 Oct '15

Hello, The issue was brought up on this list [1] that the released versions of GHC 7.8 do not work on El Capitan due to an older `unix` package. In a subsequent GHC weekly news [2], it was announced that since El Capitan wasn't yet released, it wasn't worthwhile to put more developer time into 7.8. Now that El Capitan is out, and the existing 7.8 binaries continue to not work, I'd like to reopen this issue and request a point release with an updated `unix` package. Thank you, Adam Foltzer Research Engineer Galois, Inc. [1]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009403.html [2]: https://ghc.haskell.org/trac/ghc/blog/weekly20150721#MacOSXElCapitansupport

4 6

MonadFail decisions
by Simon Peyton Jones 16 Oct '15

16 Oct '15

Dear Edward and Core Libraries Committee Can you tell us what plan you want to execute for MonadFail? Specifically, in https://wiki.haskell.org/MonadFail_Proposal · Is the specification in 1.3 what you have agreed? · Is the transition strategy in 1.7 exactly what you want? We can’t implement 8.0 without being sure of the specification! The current Phab is https://phabricator.haskell.org/D1248 Also, David, did our conversation at HX help you get un-stuck? Thanks Simon From: haskell-core-libraries(a)googlegroups.com [mailto:haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett Sent: 13 October 2015 01:43 To: core-libraries-committee(a)haskell.org Subject: [core libraries] Prelude: 3 Release Policy Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude. In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time. I'm personally considering this a very high priority for all changes to Prelude going forward. The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can look forward as well. That is a separate concern, though. I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it! All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration. Off the top of my head: * A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline. * MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full implementation of the proposal to 8.6 as well. * The Semigroup as a superclass of Monoid proposal runs into a similar clock. An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.) Observations: This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in compliance. I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may". When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff. In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail class across older GHC versions. The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window. Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast. Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass this litmus test. I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object. I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense of stability. In all of the above cases I think it actually improves upon the timeline a bit. Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee. Ideas? -Edward -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com<mailto:haskell-core-libraries+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/d/optout<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgroups.goo…>.

4 8