- ghc-devs - Haskell.org

Test message, please ignore
by Austin Seipp 15 Jun '15

15 Jun '15

If you can see this, it probably works. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Test message, please ignore
by Austin Seipp 15 Jun '15

15 Jun '15

If you can see this, it probably works. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RE: overlapping instances in 7.10.1
by Simon Peyton Jones 13 Jun '15

13 Jun '15

Sergei I finally found time to look into what is happening here. It's a good illustration of the dangers of overlapping instances. Here is the setup: * Module ResEuc_ * Contains instance (...) => Ring (ResidueE a) <---- (A) instance (..., Ring (ResidueE a)) => Field (ResidueE a) <---- (B) * Module PFact__ * Imports Pgcd_, which imports ResEuc_ * Contains code that needs (Field (ResidueE (UPol (ResidueE Integer)))) <------ (X) * To solve (X) we use instance (B) from ResEuc_ * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer)))) which we do using (A) but not (C) * Module RsePol_ * Imports PFact__ * Contains the specialised instance instance (...) => Ring (ResidueE (UPol a)) <------ (C) which overlaps instance (A) * Module Main * Needs an instance for Field (ResidueE (UPol (Residue Integer))) <------ (Y) * Although GHC *could* generate this by instance declarations, which it would do using (B) and then using (C), instead GHC cleverly sees that it has generated it before, in module PFact__, and so uses the one from PFact__. And that is what gives rise to your error So the real problem is that in PFact__, we make an instance (X) that does not see the specialised instance (C). It *cannot* see that instance because RsePol_ imports PFact__. So whatever code uses (X) is not going to see the specialised instance. I bet that this is not what you intend. This may be a latent bug in DoCon. I solved the problem by combining PFact__ and RsePol_ into a single module. Then everything works fine. What are the general lessons here? * GHC generally assumes that if it generates (C T) in one place, then it can use that anywhere in the program that (C T) is needed. That is, there is only one (C T) dictionary. * But suppose you have overlapping instance in different modules; say module A where instance C [a] module B where import A; instance C [Maybe a] If you use (C [Maybe Int]) in A, then of course we won't see the instance in B. So you'll get a different dictionary than if you compute C [Maybe Int] in module B. In short, overlapping instances are OK, but it's best to put them in the same module as the instances they overlap. Could GHC behave as if all instances were calculated afresh in the module being compiled. Yes, of course it could, but at the cost of losing the benefit of cross-module specialisation. An overloaded function specialised at, say, [Int] in one module could not be re-used in another in case the instances changed. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | Sergei Meshveliani | Sent: 23 May 2015 22:08 | To: glasgow-haskell-users(a)haskell.org | Cc: glasgow-haskell-bugs(a)haskell.org | Subject: overlapping instances in 7.10.1 | | Dear GHC developers, | | This request overrides my previous one of "7.10.1-err..." | (it is simpler and more precise). | The archive | | http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2…> | may23-2015.zip<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2…> | | presents a question about ghc-7.10.1. | | Make it, please, with ghc-7.10.1 by | | ghc $doconCpOpt -O --make Main | , | $doconCpOpt = | -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports | -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns | -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances | -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30 | | | as it is written there in README.txt. | | README.txt explains which two instances are wrongly resolved | -- as I expect. | | In ghc-7.8.2 they are resolved in a correct way | (and there is a different pragma syntax). | I conclude this from running the test in docon-2.12. | | Am I missing something? | | Please, advise, | | ------ | Sergei | | | | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

1 0

GHC build failure
by Wolfgang Jeltsch 11 Jun '15

11 Jun '15

Hi, I just updated my GHC HEAD copy via git pull and tried to rebuild GHC with BuildFlavour set to devel2. I got the following error message: ghc/InteractiveUI.hs:68:8: error: Could not find module ‘Control.DeepSeq’ It is a member of the hidden package ‘deepseq-1.4.1.1@deeps_6vMKxt5sPFR0XsbRWvvq59’. Use -v to see a list of the files searched for. Any ideas what to do? All the best, Wolfgang

5 7

Adding location information to derived code
by Jan Stolarek 11 Jun '15

11 Jun '15

Hi devs, say I have: class C a where type F a type F a = a instance C Int During compilation of "instance C Int" GHC will derive a default associated type instance "F Int = Int". That instance has no location information and so any errors that it might cause will have a very uninformative source code location 1:1. I want to fix this but I'm not sure whether it is a good idea to add location information to automatically generated code. Do we make any assumptions that derived code should have no location information? 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.

2 2

Time files... and here's another alpha HP for 7.10
by Mark Lentczner 10 Jun '15

10 Jun '15

So - I hear from a bird that 7.10.2 might be just around the corner. I'm getting ahead of the curve! I just did a fully hermetic and clean build of head of GHC 7.10 branch (what should become 7.10.2), and then brought HP up-to-date: - bootstrapped with 7.10.1 (so hptool needed fixes to build with that) - uses latest shake - built on a clean Debian Wheezy (7) install, (hence uses glibc 2.13 and should also run on Ubuntu 12.04 and later) The package versions are updated as follows: Cabal 1.22.2.0 --> 1.22.3.0 cabal-install 1.22.2.0 --> 1.22.4.0 attoparsec 0.12.1.4 --> 0.13.0.0 syb 0.4.4 --> 0.5.1 text 1.2.0.4 --> 1.2.1.1 cgi 3001.2.2.1 --> 3001.2.2.2 network 2.6.0.2 --> 2.6.2.0 network-uri 2.6.0.1 --> 2.6.0.3 QuickCheck 2.8 --> 2.8.1 hscolour 1.22 --> 1.23 GLUT 2.7.0.0 --> 2.7.0.1 GLURaw 1.5.0.0 --> 1.5.0.1 OpenGL 2.12.0.0 --> 2.12.0.1 OpenGLRaw 2.4.1.0 --> 2.5.0.0 Only package issue was: zlib 0.5.4.2 -- held back because cabal-install needs < 0.6 All the same caveats and notes from Alpha 2 still apply. All these changes are in the pre-release-2 branch on github -- I'll merge it all together later this week. There is a hp-bindist-tarball on my server: haskell-platform-7.10.1.20150528-x86_64-unknown-linux-deb7.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-7.10.1.20150528-x8…> SHA-256: b503c9e2c34c0865b5fee39444027667bb39b786fa7664029287e3bbf33379da I'll build and put up OS X version in a day or two. One last thing... I'm proposing that we name this release: Haskell Platform 7.10.2 ! - Mark

2 8

windows failure in testsuite
by Simon Peyton Jones 10 Jun '15

10 Jun '15

Windows and testsuite folk: The testsuite framework is crashing on my 32-bit Windows machine, with the error below. Happens when the stderr output differs from expected. I know that there have been recent changes in the testsuite stuff. Could you fix please? Thanks Simon =====> T4254(normal) 1587 of 4522 [2, 15, 0] cd ./indexed-types/should_fail && "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T4254.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history > T4254.comp.stderr 2>&1 Actual stderr output differs from expected: 'diff' is not recognized as an internal or external command, operable program or batch file.

2 2

GHC Weekly News - 2015/06/10
by Austin Seipp 10 Jun '15

10 Jun '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150610) Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result the current weekly notes have been slow - the current priority is the next release though, which leads us to... == 7.10.2 status == 7.10.2 is '''going to be out soon''' - our current plan is to have a release candidate on '''the weekend of Saturday the 13th''', and the final release '''the next week'''. That means if you want something fixed, you'd better hollar ''very'' soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page] shows the current set of tickets we've fixed and plan on fixing. == List chatter == - Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html - Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html - Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an `instance` clause without the `where`) - what do people think about fixing this, and are there anythings to look out for? https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html - David Luposchainsky has opened a new thread - about moving `fail` out of `Monad` and into its own typeclass, `MonadFail`. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html == Noteworthy commits == - Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading & unloading code - Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel == Closed tickets == #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: MonadFail proposal (MFP): Moving fail out of Monad
by Carter Schonwald 10 Jun '15

10 Jun '15

i'll add my token +1 to the land slide On Tue, Jun 9, 2015 at 11:19 PM, Bardur Arantsson <spam(a)scientician.net> wrote: > On 06/09/2015 10:43 PM, David Luposchainsky wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > +1 > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

Clearing up confusion about package keys, package ids, et al
by Edward Z. Yang 05 Jun '15

05 Jun '15

I have written a new wiki page which tries to explicate these concepts: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/Concepts I haven't finished writing my proposal but one thing that I am going to argue is that we are going to need *MORE* package identification concepts (sorry Simon!); e.g. reusing package keys as Nix keys just isn't going to work. Edward

1 0