From gershomb at gmail.com Tue Apr 1 04:37:00 2014 From: gershomb at gmail.com (Gershom Bazerman) Date: Tue, 01 Apr 2014 00:37:00 -0400 Subject: New GHC Features for 7.10.1 and Beyond Message-ID: <533A426C.5070108@gmail.com> There's been lots of exciting work going into the forthcoming GHC 7.8.1 release. But even with all these new features, our language is far from complete and I wouldn't want the GHC team to rest on their laurels. Especially with so much renewed community involvement in GHC development, it seems appropriate to share some ideas some of us have been discussing for future releases, and take a poll of community consensus regarding which ones people might be excited to jump in and help out with, or might find particularly helpful. One important area that needs work is exceptions. These are famously difficult, and many libraries have been written to provide checked exceptions, or unify error and exceptions in various ways. It seems to me that the problem, all along, has been that we've decided to give Haskell _imprecise exceptions_ with special semantics. It would alleviate a great deal of confusion if we implemented a -fprecise-exceptions flag that remedied this. Additionally, while we have long known that Haskell is not a "lazy" language but a "non-strict" one, our leading compiler only rarely takes advantage of this. It is well known that for every program there is a reduction strategy that preserves non-strict semantics while using as few reductions as possible. This is known as the "optimal reduction" strategy, and it is calculable and well understood. We should put some work into a -foptimal-reduction flag. Another important area of research is quantum computation. The D-Wave Two, with 512 qbits, is a commercially available quantum computer now deployed in a few leading institutions. As more and more people begin to purchase D-Wave systems for home hacking, every language worth its salt will need to be able to target this system. Now that cross compilation is more fully supported, it would be good to start putting work into a dwave backend. We've also seen a lot of interest in distribution and cloud computing. From the articles I've read, efficient concurrent programming involves using node.js, so I think we should put some work into writing a new-new-new-IO Manager built on top of this technology. Furthermore, it's ridiculous that while Haskell allows simple concurrent and distributed programming, it offers no simple way to set up a distributed environment. Work should be put into a compiler mode that provisions cloud resources automatically and distributes the target binary among them, with a flag such as: -fvia-s3 _credit_card_number_ There are a few cases where a good idea in GHC can be taken further, and I don't know why we haven't tried already. For example, we've found that despite introducing some occasional problems, the state hack also has drastically improved performance. Since it works so well, we should provide a dual to -fno-state-hack, -fmore-state-hack, for those who really need every last drop of performance. Similarly, now we have type holes that let us see what types should be inserted in various spots. -fvalue-holes is the next logical step, to tell us what terms we should be writing. Also, while we've put so much emphasis on correctness, we've also loosened the bolts optionally the other way, with flags such as -XIncoherentInstances. Along the same lines, I would like to introduce -XImpossibleInstances to let us express such useful things as "instance Int String," "instance IO Comonad," and "instance data if". -fdefer-type-errors allows us to defer type errors to runtime. Having spent some time with JavaScript lately, I think this doesn't go nearly far enough. It would be good to run programs with other sorts of problems as well, for educational purposes and for quick hacking. So work should be put into a -fdefer-scope-errors flag, as well as -fon-error-resume-next, which has done wonders for the resilience of Visual Basic code (see also the wildly useful ability to set the top level error handler in PHP). With all these features put together, we have a powerful new way to approach Haskell programming, and it would be good to enable them by default on .ilhs files (illiterate haskell). It also was pointed out to me recently by Jason Dagit that while we have had debates and confusion over closed and open type families and functions for years, topologists have solved this problem elegantly. With some basic point set topology under one's belt, a -XClopenTypeFamilies extension seems almost trivial to implement. Finally, I'm very sorry to see that my proposal for youtube syntax has languished, and I hope it can be revived: http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html HTH HAND, Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Tue Apr 1 05:07:03 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 01 Apr 2014 14:07:03 +0900 (JST) Subject: New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Hi Gershom, > We've also seen a lot of interest in distribution and cloud computing. > From the articles I've read, efficient concurrent programming involves > using node.js, so I think we should put some work into writing a > new-new-new-IO Manager built on top of this technology. As a member of Mio developers, I don't understand this sentence. Would you concretely explain what kind of node.js technologies should be taken into new-new-new-IO Manager? --Kazu From michael at snoyman.com Tue Apr 1 05:28:08 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 1 Apr 2014 08:28:08 +0300 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: <20140401.140703.1346190877164591597.kazu@iij.ad.jp> References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Message-ID: On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto wrote: > Hi Gershom, > > > We've also seen a lot of interest in distribution and cloud computing. > > From the articles I've read, efficient concurrent programming involves > > using node.js, so I think we should put some work into writing a > > new-new-new-IO Manager built on top of this technology. > > As a member of Mio developers, I don't understand this sentence. Would > you concretely explain what kind of node.js technologies should be > taken into new-new-new-IO Manager? > > It's really simple: node.js is webscale, Mio is not. I'm sorry, but you simply didn't do a good enough job making sure that random packets were lost when sending network traffic, or that writing data to disk may sporadically fail. Better luck next time. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Tue Apr 1 05:59:19 2014 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue, 1 Apr 2014 16:59:19 +1100 Subject: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond In-Reply-To: References: <533A426C.5070108@gmail.com> <20140401.140703.1346190877164591597.kazu@iij.ad.jp> Message-ID: <20140401165919.9b035705b86bd289ca17b99d@mega-nerd.com> Michael Snoyman wrote: > On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto wrote: > > > Hi Gershom, > > > > > We've also seen a lot of interest in distribution and cloud computing. > > > From the articles I've read, efficient concurrent programming involves > > > using node.js, so I think we should put some work into writing a > > > new-new-new-IO Manager built on top of this technology. > > > > As a member of Mio developers, I don't understand this sentence. Would > > you concretely explain what kind of node.js technologies should be > > taken into new-new-new-IO Manager? > > > > > It's really simple: node.js is webscale, Mio is not. I'm sorry, but you > simply didn't do a good enough job making sure that random packets were > lost when sending network traffic, or that writing data to disk may > sporadically fail. Better luck next time. I think Michael about sums it up. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From dan.doel at gmail.com Tue Apr 1 06:54:14 2014 From: dan.doel at gmail.com (Dan Doel) Date: Tue, 1 Apr 2014 02:54:14 -0400 Subject: Eta Reduction Message-ID: In the past year or two, there have been multiple performance problems in various areas related to the fact that lambda abstraction is not free, though we tend to think of it as so. A major example of this was deriving of Functor. If we were to derive Functor for lists, we would end up with something like: instance Functor [] where fmap _ [] = [] fmap f (x:xs) = f x : fmap (\y -> f y) xs This definition is O(n^2) when fully evaluated,, because it causes O(n) eta expansions of f, so we spend time following indirections proportional to the depth of the element in the list. This has been fixed in 7.8, but there are other examples. I believe lens, [1] for instance, has some stuff in it that works very hard to avoid this sort of cost; and it's not always as easy to avoid as the above example. Composing with a newtype wrapper, for instance, causes an eta expansion that can only be seen as such at the core level. The obvious solution is: do eta reduction. However, this is not operationally sound currently. The problem is that seq is capable of telling the difference between the following two expressions: undefined \x -> undefined x The former causes seq to throw an exception, while the latter is considered defined enough to not do so. So, if we eta reduce, we can cause terminating programs to diverge if they make use of this feature. Luckily, there is a solution. Semantically one would usually identify the above two expressions. While I do believe one could construct a semantics that does distinguish them, it is not the usual practice. This suggests that there is a way to not distinguish them, perhaps even including seq. After all, the specification of seq is monotone and continuous regardless of whether we unify ? with \x -> ? x or insert an extra element for the latter. The currently problematic case is function spaces, so I'll focus on it. How should: seq : (a -> b) -> c -> c act? Well, other than an obvious bottom, we need to emit bottom whenever our given function is itself bottom at every input. This may first seem like a problem, but it is actually quite simple. Without loss of generality, let us assume that we can enumerate the type a. Then, we can feed these values to the function, and check their results for bottom. Conal Elliot has prior art for this sort of thing with his unamb [2] package. For each value x :: a, simply compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find one, we know the function is non-bottom, and we can return our value of c. If we never finish searching, then the function must be bottom, and seq should not terminate, so we have satisfied the specification. Now, some may complain about the enumeration above. But this, too, is a simple matter. It is well known that Haskell programs are denumerable. So it is quite easy to enumerate all Haskell programs that produce a value, check whether that value has the type we're interested in, and compute said value. All of this can be done in Haskell. Thus, every Haskell type is programatically enumerable in Haskell, and we can use said enumeration in our implementation of seq for function types. I have discussed this with Russell O'Connor [3], and he assures me that this argument should be sufficient even if we consider semantic models of Haskell that contain values not denoted by any Haskell program, so we should be safe there. The one possible caveat is that this implementation of seq is not operationally uniform across all types, so the current fully polymorphic type of seq may not make sense. But moving back to a type class based approach isn't so bad, and this time we will have a semantically sound backing, instead of just having a class with the equivalent of the current magic function in it. Once this machinery is in place, we can eta reduce to our hearts' content, and not have to worry about breaking semantics. We'd no longer put the burden on programmers to use potentially unsafe hacks to avoid eta expansions. I apologize for not sketching an implementation of the above algorithm, but I'm sure it should be elementary enough to make it into GHC in the next couple versions. Everyone learns about this type of thing in university computer science programs, no? Thoughts? Comments? Questions? Cheers, -- Dan [1] http://hackage.haskell.org/package/lens [2] http://hackage.haskell.org/package/unamb [3] http://r6.ca/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Tue Apr 1 07:42:26 2014 From: voldermort at hotmail.com (harry) Date: Tue, 1 Apr 2014 00:42:26 -0700 (PDT) Subject: Buildbots Message-ID: <1396338146446-5746770.post@n5.nabble.com> It having been suggested that a buildbot for Windows may be needed, and it being possible that I may receive permission from management for setting one up in my department's server room, I set about attempting to discover what this actually entails. A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, which tells me that "Buildbot is currently down, and we are working on a replacement. See Builder for more details." If I follow the 'down' link , I get to the GHC status April 2010 page, which says that buildbot has been abandoned, suggesting that the page should be deleted. Could someone confirm before I go ahead and delete it? The Builder page has clear instructions on how to set up a build slave, and a link to the build results. The build results contains an assortment of dud links and builds from August and earlier. What is the current state of automated builds? -- View this message in context: http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From karel.gardas at centrum.cz Tue Apr 1 07:57:34 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 01 Apr 2014 09:57:34 +0200 Subject: Buildbots In-Reply-To: <1396338146446-5746770.post@n5.nabble.com> References: <1396338146446-5746770.post@n5.nabble.com> Message-ID: <533A716E.1080003@centrum.cz> Hi, Gabor Pali provides his own builder server infrastructure for now when GHC's HQ is not working. Please have a look at http://haskell.inf.elte.hu/builders/ and contact Gabor for more details (he is cced). Thanks! Karel On 04/ 1/14 09:42 AM, harry wrote: > It having been suggested that a buildbot for Windows may be needed, and it > being possible that I may receive permission from management for setting one > up in my department's server room, I set about attempting to discover what > this actually entails. > > A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, > which tells me that "Buildbot is currently down, and we are working on a > replacement. See Builder for more details." If I follow the 'down' link , I > get to the GHC status April 2010 page, which says that buildbot has been > abandoned, suggesting that the page should be deleted. Could someone confirm > before I go ahead and delete it? > > The Builder page has clear instructions on how to set up a build slave, and > a link to the build results. The build results contains an assortment of dud > links and builds from August and earlier. > > What is the current state of automated builds? > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From johan.tibell at gmail.com Tue Apr 1 07:58:44 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 1 Apr 2014 09:58:44 +0200 Subject: Buildbots In-Reply-To: <1396338146446-5746770.post@n5.nabble.com> References: <1396338146446-5746770.post@n5.nabble.com> Message-ID: We now have a (Linux) travis-ci buildbot so we should be able to use whatever script that buildbot runs. To make a full validate you simply check out the source repos and run: CPUS=N sh validate (CPUS=N is optional of course.) On Tue, Apr 1, 2014 at 9:42 AM, harry wrote: > It having been suggested that a buildbot for Windows may be needed, and it > being possible that I may receive permission from management for setting > one > up in my department's server room, I set about attempting to discover what > this actually entails. > > A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, > which tells me that "Buildbot is currently down, and we are working on a > replacement. See Builder for more details." If I follow the 'down' link , I > get to the GHC status April 2010 page, which says that buildbot has been > abandoned, suggesting that the page should be deleted. Could someone > confirm > before I go ahead and delete it? > > The Builder page has clear instructions on how to set up a build slave, and > a link to the build results. The build results contains an assortment of > dud > links and builds from August and earlier. > > What is the current state of automated builds? > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html > Sent from the Haskell - Glasgow-haskell-users mailing list archive at > Nabble.com. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Tue Apr 1 08:07:10 2014 From: voldermort at hotmail.com (harry) Date: Tue, 1 Apr 2014 01:07:10 -0700 (PDT) Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> Message-ID: <1396339630722-5746774.post@n5.nabble.com> Johan Tibell-2 wrote > We now have a (Linux) travis-ci buildbot so we should be able to use > whatever script that buildbot runs. Does this mean that the Builder page is also no longer relevant? And if so, how could a Windows buildbot be set up? -- View this message in context: http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770p5746774.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From johan.tibell at gmail.com Tue Apr 1 08:12:39 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 1 Apr 2014 10:12:39 +0200 Subject: Buildbots In-Reply-To: <1396339630722-5746774.post@n5.nabble.com> References: <1396338146446-5746770.post@n5.nabble.com> <1396339630722-5746774.post@n5.nabble.com> Message-ID: On Tue, Apr 1, 2014 at 10:07 AM, harry wrote: > Johan Tibell-2 wrote > > We now have a (Linux) travis-ci buildbot so we should be able to use > > whatever script that buildbot runs. > > Does this mean that the Builder page is also no longer relevant? And if so, > how could a Windows buildbot be set up? > I don't know whether the old buildbot is still in use. I haven't seen any emails from it in quite a while. I'll wait for some other people on the list to chime in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 1 10:25:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 10:25:35 +0000 Subject: Buildbots In-Reply-To: <1396338146446-5746770.post@n5.nabble.com> References: <1396338146446-5746770.post@n5.nabble.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> Friends The nightly-build infrastructure for GHC is in disarray, and we could really do with help. We really want * Continuous integration so that new test failures show up fast * Nightly builds on a variety of platforms, giving snapshots that are easy to install Originally we used Buildbot (http://buildbot.net/). Then in 2010 Ian Lynagh put a lot of work into a build-bot infrastructure, implemented in Haskell as an open-source project, GHC Builder (?https://ghc.haskell.org/trac/ghc/wiki/Builder). See https://ghc.haskell.org/trac/ghc/wiki/Status/Apr10#Nightlybuilds for the reasoning at the time. As I understand it, Builder never "caught fire", and now that Ian has moved on I don't know that anyone is maintaining it; nor are the various builders working so far as I know. Perhaps competing technology has moved on, so that the original rationale no longer holds? I'm not sure. Regardless, we lack leadership in this area. Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Others have indicated interest/willingness. But it would be fantastic to have a person, or (more plausibly) a small group who assumed leadership. An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. Others will be better informed than me about all this... we'd love to hear from you. Thank you! Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of harry | Sent: 01 April 2014 08:42 | To: glasgow-haskell-users at haskell.org | Subject: Buildbots | | It having been suggested that a buildbot for Windows may be needed, and | it | being possible that I may receive permission from management for setting | one | up in my department's server room, I set about attempting to discover | what | this actually entails. | | A Google search led me to https://ghc.haskell.org/trac/ghc/wiki/BuildBot, | which tells me that "Buildbot is currently down, and we are working on a | replacement. See Builder for more details." If I follow the 'down' link , | I | get to the GHC status April 2010 page, which says that buildbot has been | abandoned, suggesting that the page should be deleted. Could someone | confirm | before I go ahead and delete it? | | The Builder page has clear instructions on how to set up a build slave, | and | a link to the build results. The build results contains an assortment of | dud | links and builds from August and earlier. | | What is the current state of automated builds? | | | | -- | View this message in context: | http://haskell.1045720.n5.nabble.com/Buildbots-tp5746770.html | Sent from the Haskell - Glasgow-haskell-users mailing list archive at | Nabble.com. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From mail at joachim-breitner.de Tue Apr 1 10:46:05 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 12:46:05 +0200 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1396349165.2683.14.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: > Joachim Breitner has set up Travis-CI. (I don't know exactly what > that is, but it sounds useful.) Travis is a free cloud service that runs arbitrary tests (in our case, a stripped version of validate) upon pushes to git repositories on github. I set it up to validate our master, so we get a nice history of successes and failures on https://travis-ci.org/nomeata/ghc-complete/builds and I get mails when things fail; that is when I send hopefully polite enough mails to ghc-dev, asking people to fix their commits. (Unless I broke it myself; then I silently fix it and hide.) It is a makeshift solution until we get our own infrastructure working. > An early question would be: to continue to use a DIY system (Builder), > or to move to some other better-supported (but perhaps less malleable) > system. I don't even know what the options are. Sigh, test infrastructure are like content management systems: There are plenty out there to choose from, all can do lots of things one does not need, but none can do all, so one starts writing something selfmade, which eventually evolves in yet another of these beasts, just with fewer users. I?d recommend a move to existing, proven tools. Unfortunately, I cannot give advice as to what tool to move to. But if all these? projects are happy with buildbot, it might not be the worst choice. ? http://trac.buildbot.net/wiki/SuccessStories Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Apr 1 10:57:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 10:57:00 +0000 Subject: Haskell Support on Windows In-Reply-To: <1396268819897-5746711.post@n5.nabble.com> References: <1396268819897-5746711.post@n5.nabble.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D34C4@DB3PRD3001MB020.064d.mgd.msft.net> | I've been getting the impression that a lot of the stickier GHC bugs are | Windows specific, while very few GHC hackers actually use Windows, other | than to ensure that GHC works on it. ... | Perhaps it should be "demoted" to second-tier GHC support as well, at | least to the extent that Windows bugs won't hold up a release? That's true. But many, many people *use* GHC on Windows. It would be terribly sad to abandon them. What we need is more developers to volunteer to help look after the Windows version of GHC. One or two are doing so, but we need more. Please! Simon From alain.odea at gmail.com Tue Apr 1 11:08:13 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 11:08:13 +0000 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: Hi Joachim: From what I understand Travis CI limits running time for each build. We may be able to create binaries of stage1 and/or stage2 in one build and test them in another. We could also fan out the test process using a Build Matrix to let GHC's full suite fit into the time limit as fragments. That would require some changes to the testsuite or some lengthy build scripts for each segment that explicitly run many "make TEST=sometest" commands. I had to do something similar at Verafin because the whole test suite was taking too long as a whole unit. I split it into builds for each separate module and used more build agents so they could run in parallel. Verafin is using TeamCity, but I think the concepts are achievable in Buildbot or Travis CI. In my opinion, the best build and CI system is the one you can get working. Best, Alain > On Apr 1, 2014, at 10:46, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: >> Joachim Breitner has set up Travis-CI. (I don't know exactly what >> that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tests (in our case, a > stripped version of validate) upon pushes to git repositories on github. > I set it up to validate our master, so we get a nice history of > successes and failures on > https://travis-ci.org/nomeata/ghc-complete/builds > and I get mails when things fail; that is when I send hopefully polite > enough mails to ghc-dev, asking people to fix their commits. > > (Unless I broke it myself; then I silently fix it and hide.) > > It is a makeshift solution until we get our own infrastructure working. > >> An early question would be: to continue to use a DIY system (Builder), >> or to move to some other better-supported (but perhaps less malleable) >> system. I don't even know what the options are. > > Sigh, test infrastructure are like content management systems: There are > plenty out there to choose from, all can do lots of things one does not > need, but none can do all, so one starts writing something selfmade, > which eventually evolves in yet another of these beasts, just with fewer > users. > > I?d recommend a move to existing, proven tools. Unfortunately, I cannot > give advice as to what tool to move to. But if all these? projects are > happy with buildbot, it might not be the worst choice. > > ? http://trac.buildbot.net/wiki/SuccessStories > > Greetings, > Joachim > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Tue Apr 1 11:11:04 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 01 Apr 2014 13:11:04 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <1396350664.2683.17.camel@kirk> Hi, Am Dienstag, den 01.04.2014, 11:08 +0000 schrieb Alain O'Dea: > From what I understand Travis CI limits running time for each build. > We may be able to create binaries of stage1 and/or stage2 in one build > and test them in another. We could also fan out the test process > using a Build Matrix to let GHC's full suite fit into the time limit > as fragments. That would require some changes to the testsuite or > some lengthy build scripts for each segment that explicitly run many > "make TEST=sometest" commands. The main problem with Travis is that it only tests on one architecture. There are more (e.g. very undetailed reporting compared to a buildbot waterfall/grid) Hence: Travis is _not_ going to be a solution for us; we will want our own infrastructure. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Tue Apr 1 11:11:56 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 11:11:56 +0000 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <299206C2-6350-4B07-87C5-2FF3608E88A8@gmail.com> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> <214060E8-ABC4-4C8B-B6CC-91B0C0A304F4@gmail.com> <299206C2-6350-4B07-87C5-2FF3608E88A8@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D358B@DB3PRD3001MB020.064d.mgd.msft.net> These "absent" thunks appear when the strictness analyser works out that a function does not use an argument at all. Suppose 'f' does not use its first argument. Then a call f (...big expression...) will be replaced with f (absentError "blah") Such thunks almost invariably turn out to be dead code in the end, and are discarded. It's very unusual for them to survive to the end of compilation, let alone as a top-level value. But it's not impossible. Just for curiosity, can you compile with -dverbose-core2core, and leave the results somewhere I can see them? In short, it doesn't look as if there is anything wrong. If there's a good reason you want to see the unfolding anyway, that's not impossible, but at least you understand what is happening now. Simon | -----Original Message----- | From: Christiaan Baaij [mailto:christiaan.baaij at gmail.com] | Sent: 28 March 2014 09:57 | To: Simon Peyton Jones | Cc: glasgow-haskell-users | Subject: Re: GHC API: getting the unfolding of a "strange" Id | | | > I don't really get why this GHC.TypeLits constraint is a bottom | dictionary... | > Is it because all Coercions/Constraints are bottom? | > Is there perhaps a set of flags I can use so that I can see the Core | term corresponding to CLaSH.Sized.Fixed.$fNumFixed2 during compilation? | | | I guess I straight away answer my own question, sorry for the noise: | | CLaSH.Sized.Fixed.$fNumFixed2 | :: forall (n_a5SH :: GHC.TypeLits.Nat). 1 GHC.TypeLits.<= n_a5SH | [GblId, Str=DmdType b] | CLaSH.Sized.Fixed.$fNumFixed2 = | \ (@ (n_a5SH :: GHC.TypeLits.Nat)) -> | Control.Exception.Base.absentError | @ (1 GHC.TypeLits.<= n_a5SH) | "ww_s9JT{v} [lid] 1 base:GHC.TypeLits.<={tc r1W} n{tv a5SH} [tv]"# | | I must say... I have never seen, in any of my programs, the error that | Control.Exception.Base.absentError is supposed to give: | absentError s = error ("Oops! Entered absent arg " ++ | unpackCStringUtf8# s) | | -- Christiaan From alain.odea at gmail.com Tue Apr 1 11:22:16 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 11:22:16 +0000 Subject: Buildbots In-Reply-To: <1396350664.2683.17.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: <293EC480-09EF-43AD-8D36-B76F88033C84@gmail.com> Hi, > On Apr 1, 2014, at 11:11, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 01.04.2014, 11:08 +0000 schrieb Alain O'Dea: >> From what I understand Travis CI limits running time for each build. >> We may be able to create binaries of stage1 and/or stage2 in one build >> and test them in another. We could also fan out the test process >> using a Build Matrix to let GHC's full suite fit into the time limit >> as fragments. That would require some changes to the testsuite or >> some lengthy build scripts for each segment that explicitly run many >> "make TEST=sometest" commands. > > The main problem with Travis is that it only tests on one architecture. > There are more (e.g. very undetailed reporting compared to a buildbot > waterfall/grid) Good points. > Hence: Travis is _not_ going to be a solution for us; we will want our > own infrastructure. I'm happy to assist with getting whatever system fits the bill working. It seems like Buildbot should. Where can we get infrastructure on multiple architectures easily? I imagine we may need to mix and match. > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0x4743206C > Debian Developer: nomeata at debian.org From karel.gardas at centrum.cz Tue Apr 1 11:45:58 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 01 Apr 2014 13:45:58 +0200 Subject: Buildbots In-Reply-To: <1396350664.2683.17.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> Message-ID: <533AA6F6.1090309@centrum.cz> Hi, I'm curious why not to use what's already written by Ian and others and which is currently running again? E.g. Janos Gabor Pali was so nice to start and keep builder server running on http://haskell.inf.elte.hu/builders/ Just few are there, but others may be added. Just send email to Janos to get the credentials and more information about what to get from where (recent builder client is needed). Perhaps we shall more advertise this option on GHC's builder wiki page? Thanks, Karel On 04/ 1/14 01:11 PM, Joachim Breitner wrote: > Hence: Travis is _not_ going to be a solution for us; we will want our > own infrastructure. From simonpj at microsoft.com Tue Apr 1 12:03:12 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 1 Apr 2014 12:03:12 +0000 Subject: Buildbots In-Reply-To: <533AA6F6.1090309@centrum.cz> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Karel Gardas | Sent: 01 April 2014 12:46 | To: Joachim Breitner; ghc-devs at haskell.org; P?li G?bor J?nos | Cc: glasgow-haskell-users at haskell.org | Subject: Re: Buildbots | | | Hi, | | I'm curious why not to use what's already written by Ian and others and | which is currently running again? E.g. Janos Gabor Pali was so nice to | start and keep builder server running on | http://haskell.inf.elte.hu/builders/ | | Just few are there, but others may be added. Just send email to Janos to | get the credentials and more information about what to get from where | (recent builder client is needed). | | Perhaps we shall more advertise this option on GHC's builder wiki page? | | Thanks, | Karel | | | On 04/ 1/14 01:11 PM, Joachim Breitner wrote: | > Hence: Travis is _not_ going to be a solution for us; we will want our | > own infrastructure. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From alain.odea at gmail.com Tue Apr 1 12:17:26 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 12:17:26 +0000 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm going to read up on Ian's Buildbot work and experiment with that in the meantime. If other challenges come up I'm glad to dive in and help. > On Apr 1, 2014, at 12:03, Simon Peyton Jones wrote: > > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the options. But it depends on a critical evaluation of what the advantages and disadvantages of different approaches are > > Simon > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Karel Gardas > | Sent: 01 April 2014 12:46 > | To: Joachim Breitner; ghc-devs at haskell.org; P?li G?bor J?nos > | Cc: glasgow-haskell-users at haskell.org > | Subject: Re: Buildbots > | > | > | Hi, > | > | I'm curious why not to use what's already written by Ian and others and > | which is currently running again? E.g. Janos Gabor Pali was so nice to > | start and keep builder server running on > | http://haskell.inf.elte.hu/builders/ > | > | Just few are there, but others may be added. Just send email to Janos to > | get the credentials and more information about what to get from where > | (recent builder client is needed). > | > | Perhaps we shall more advertise this option on GHC's builder wiki page? > | > | Thanks, > | Karel > | > | > | On 04/ 1/14 01:11 PM, Joachim Breitner wrote: > | > Hence: Travis is _not_ going to be a solution for us; we will want our > | > own infrastructure. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From jwlato at gmail.com Tue Apr 1 13:17:31 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 06:17:31 -0700 Subject: Eta Reduction In-Reply-To: References: Message-ID: I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. John L. On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: > In the past year or two, there have been multiple performance problems in > various areas related to the fact that lambda abstraction is not free, > though we > tend to think of it as so. A major example of this was deriving of > Functor. If we > were to derive Functor for lists, we would end up with something like: > > instance Functor [] where > fmap _ [] = [] > fmap f (x:xs) = f x : fmap (\y -> f y) xs > > This definition is O(n^2) when fully evaluated,, because it causes O(n) eta > expansions of f, so we spend time following indirections proportional to > the > depth of the element in the list. This has been fixed in 7.8, but there are > other examples. I believe lens, [1] for instance, has some stuff in it that > works very hard to avoid this sort of cost; and it's not always as easy to > avoid > as the above example. Composing with a newtype wrapper, for instance, > causes an > eta expansion that can only be seen as such at the core level. > > The obvious solution is: do eta reduction. However, this is not > operationally > sound currently. The problem is that seq is capable of telling the > difference > between the following two expressions: > > undefined > \x -> undefined x > > The former causes seq to throw an exception, while the latter is considered > defined enough to not do so. So, if we eta reduce, we can cause terminating > programs to diverge if they make use of this feature. > > Luckily, there is a solution. > > Semantically one would usually identify the above two expressions. While I > do > believe one could construct a semantics that does distinguish them, it is > not > the usual practice. This suggests that there is a way to not distinguish > them, > perhaps even including seq. After all, the specification of seq is > monotone and > continuous regardless of whether we unify ? with \x -> ? x or insert an > extra > element for the latter. > > The currently problematic case is function spaces, so I'll focus on it. How > should: > > seq : (a -> b) -> c -> c > > act? Well, other than an obvious bottom, we need to emit bottom whenever > our > given function is itself bottom at every input. This may first seem like a > problem, but it is actually quite simple. Without loss of generality, let > us > assume that we can enumerate the type a. Then, we can feed these values to > the > function, and check their results for bottom. Conal Elliot has prior art > for > this sort of thing with his unamb [2] package. For each value x :: a, > simply > compute 'f x `seq` ()' in parallel, and look for any successes. If we ever > find > one, we know the function is non-bottom, and we can return our value of c. > If we > never finish searching, then the function must be bottom, and seq should > not > terminate, so we have satisfied the specification. > > Now, some may complain about the enumeration above. But this, too, is a > simple > matter. It is well known that Haskell programs are denumerable. So it is > quite > easy to enumerate all Haskell programs that produce a value, check whether > that > value has the type we're interested in, and compute said value. All of > this can > be done in Haskell. Thus, every Haskell type is programatically enumerable > in > Haskell, and we can use said enumeration in our implementation of seq for > function types. I have discussed this with Russell O'Connor [3], and he > assures > me that this argument should be sufficient even if we consider semantic > models > of Haskell that contain values not denoted by any Haskell program, so we > should > be safe there. > > The one possible caveat is that this implementation of seq is not > operationally > uniform across all types, so the current fully polymorphic type of seq may > not > make sense. But moving back to a type class based approach isn't so bad, > and > this time we will have a semantically sound backing, instead of just > having a > class with the equivalent of the current magic function in it. > > Once this machinery is in place, we can eta reduce to our hearts' content, > and > not have to worry about breaking semantics. We'd no longer put the burden > on > programmers to use potentially unsafe hacks to avoid eta expansions. I > apologize > for not sketching an implementation of the above algorithm, but I'm sure it > should be elementary enough to make it into GHC in the next couple > versions. > Everyone learns about this type of thing in university computer science > programs, no? > > Thoughts? Comments? Questions? > > Cheers, > -- Dan > > [1] http://hackage.haskell.org/package/lens > [2] http://hackage.haskell.org/package/unamb > [3] http://r6.ca/ > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 1 13:28:23 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 09:28:23 -0400 Subject: Eta Reduction In-Reply-To: References: Message-ID: Can we throw some whole program partial evaluation with a termination decision oracle into the mix? On Tuesday, April 1, 2014, John Lato wrote: > I think this is a great idea and should become a top priority. I would > probably start by switching to a type-class-based seq, after which perhaps > the next step forward would become more clear. > > John L. > On Apr 1, 2014 2:54 AM, "Dan Doel" > > wrote: > >> In the past year or two, there have been multiple performance problems in >> various areas related to the fact that lambda abstraction is not free, >> though we >> tend to think of it as so. A major example of this was deriving of >> Functor. If we >> were to derive Functor for lists, we would end up with something like: >> >> instance Functor [] where >> fmap _ [] = [] >> fmap f (x:xs) = f x : fmap (\y -> f y) xs >> >> This definition is O(n^2) when fully evaluated,, because it causes O(n) >> eta >> expansions of f, so we spend time following indirections proportional to >> the >> depth of the element in the list. This has been fixed in 7.8, but there >> are >> other examples. I believe lens, [1] for instance, has some stuff in it >> that >> works very hard to avoid this sort of cost; and it's not always as easy >> to avoid >> as the above example. Composing with a newtype wrapper, for instance, >> causes an >> eta expansion that can only be seen as such at the core level. >> >> The obvious solution is: do eta reduction. However, this is not >> operationally >> sound currently. The problem is that seq is capable of telling the >> difference >> between the following two expressions: >> >> undefined >> \x -> undefined x >> >> The former causes seq to throw an exception, while the latter is >> considered >> defined enough to not do so. So, if we eta reduce, we can cause >> terminating >> programs to diverge if they make use of this feature. >> >> Luckily, there is a solution. >> >> Semantically one would usually identify the above two expressions. While >> I do >> believe one could construct a semantics that does distinguish them, it is >> not >> the usual practice. This suggests that there is a way to not distinguish >> them, >> perhaps even including seq. After all, the specification of seq is >> monotone and >> continuous regardless of whether we unify ? with \x -> ? x or insert an >> extra >> element for the latter. >> >> The currently problematic case is function spaces, so I'll focus on it. >> How >> should: >> >> seq : (a -> b) -> c -> c >> >> act? Well, other than an obvious bottom, we need to emit bottom whenever >> our >> given function is itself bottom at every input. This may first seem like a >> problem, but it is actually quite simple. Without loss of generality, let >> us >> assume that we can enumerate the type a. Then, we can feed these values >> to the >> function, and check their results for bottom. Conal Elliot has prior art >> for >> this sort of thing with his unamb [2] package. For each value x :: a, >> simply >> compute 'f x `seq` ()' in parallel, and look for any successes. If we >> ever find >> one, we know the function is non-bottom, and we can return our value of >> c. If we >> never finish searching, then the function must be bottom, and seq should >> not >> terminate, so we have satisfied the specification. >> >> Now, some may complain about the enumeration above. But this, too, is a >> simple >> matter. It is well known that Haskell programs are denumerable. So it is >> quite >> easy to enumerate all Haskell programs that produce a value, check >> whether that >> value has the type we're interested in, and compute said value. All of >> this can >> be done in Haskell. Thus, every Haskell type is programatically >> enumerable in >> Haskell, and we can use said enumeration in our implementation of seq for >> function types. I have discussed this with Russell O'Connor [3], and he >> assures >> me that this argument should be sufficient even if we consider semantic >> models >> of Haskell that contain values not denoted by any Haskell program, so we >> should >> be safe there. >> >> The one possible caveat is that this implementation of seq is not >> operationally >> uniform across all types, so the current fully polymorphic type of seq >> may not >> make sense. But moving back to a type class based approach isn't so bad, >> and >> this time we will have a semantically sound backing, instead of just >> having a >> class with the equivalent of the current magic function in it. >> >> Once this machinery is in place, we can eta reduce to our hearts' >> content, and >> not have to worry about breaking semantics. We'd no longer put the burden >> on >> programmers to use potentially unsafe hacks to avoid eta expansions. I >> apologize >> for not sketching an implementation of the above algorithm, but I'm sure >> it >> should be elementary enough to make it into GHC in the next couple >> versions. >> Everyone learns about this type of thing in university computer science >> programs, no? >> >> Thoughts? Comments? Questions? >> >> Cheers, >> -- Dan >> >> [1] http://hackage.haskell.org/package/lens >> [2] http://hackage.haskell.org/package/unamb >> [3] http://r6.ca/ >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Apr 1 14:32:27 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 1 Apr 2014 10:32:27 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: John, Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". -Edward On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: > I think this is a great idea and should become a top priority. I would > probably start by switching to a type-class-based seq, after which perhaps > the next step forward would become more clear. > > John L. > On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: > >> In the past year or two, there have been multiple performance problems in >> various areas related to the fact that lambda abstraction is not free, >> though we >> tend to think of it as so. A major example of this was deriving of >> Functor. If we >> were to derive Functor for lists, we would end up with something like: >> >> instance Functor [] where >> fmap _ [] = [] >> fmap f (x:xs) = f x : fmap (\y -> f y) xs >> >> This definition is O(n^2) when fully evaluated,, because it causes O(n) >> eta >> expansions of f, so we spend time following indirections proportional to >> the >> depth of the element in the list. This has been fixed in 7.8, but there >> are >> other examples. I believe lens, [1] for instance, has some stuff in it >> that >> works very hard to avoid this sort of cost; and it's not always as easy >> to avoid >> as the above example. Composing with a newtype wrapper, for instance, >> causes an >> eta expansion that can only be seen as such at the core level. >> >> The obvious solution is: do eta reduction. However, this is not >> operationally >> sound currently. The problem is that seq is capable of telling the >> difference >> between the following two expressions: >> >> undefined >> \x -> undefined x >> >> The former causes seq to throw an exception, while the latter is >> considered >> defined enough to not do so. So, if we eta reduce, we can cause >> terminating >> programs to diverge if they make use of this feature. >> >> Luckily, there is a solution. >> >> Semantically one would usually identify the above two expressions. While >> I do >> believe one could construct a semantics that does distinguish them, it is >> not >> the usual practice. This suggests that there is a way to not distinguish >> them, >> perhaps even including seq. After all, the specification of seq is >> monotone and >> continuous regardless of whether we unify ? with \x -> ? x or insert an >> extra >> element for the latter. >> >> The currently problematic case is function spaces, so I'll focus on it. >> How >> should: >> >> seq : (a -> b) -> c -> c >> >> act? Well, other than an obvious bottom, we need to emit bottom whenever >> our >> given function is itself bottom at every input. This may first seem like a >> problem, but it is actually quite simple. Without loss of generality, let >> us >> assume that we can enumerate the type a. Then, we can feed these values >> to the >> function, and check their results for bottom. Conal Elliot has prior art >> for >> this sort of thing with his unamb [2] package. For each value x :: a, >> simply >> compute 'f x `seq` ()' in parallel, and look for any successes. If we >> ever find >> one, we know the function is non-bottom, and we can return our value of >> c. If we >> never finish searching, then the function must be bottom, and seq should >> not >> terminate, so we have satisfied the specification. >> >> Now, some may complain about the enumeration above. But this, too, is a >> simple >> matter. It is well known that Haskell programs are denumerable. So it is >> quite >> easy to enumerate all Haskell programs that produce a value, check >> whether that >> value has the type we're interested in, and compute said value. All of >> this can >> be done in Haskell. Thus, every Haskell type is programatically >> enumerable in >> Haskell, and we can use said enumeration in our implementation of seq for >> function types. I have discussed this with Russell O'Connor [3], and he >> assures >> me that this argument should be sufficient even if we consider semantic >> models >> of Haskell that contain values not denoted by any Haskell program, so we >> should >> be safe there. >> >> The one possible caveat is that this implementation of seq is not >> operationally >> uniform across all types, so the current fully polymorphic type of seq >> may not >> make sense. But moving back to a type class based approach isn't so bad, >> and >> this time we will have a semantically sound backing, instead of just >> having a >> class with the equivalent of the current magic function in it. >> >> Once this machinery is in place, we can eta reduce to our hearts' >> content, and >> not have to worry about breaking semantics. We'd no longer put the burden >> on >> programmers to use potentially unsafe hacks to avoid eta expansions. I >> apologize >> for not sketching an implementation of the above algorithm, but I'm sure >> it >> should be elementary enough to make it into GHC in the next couple >> versions. >> Everyone learns about this type of thing in university computer science >> programs, no? >> >> Thoughts? Comments? Questions? >> >> Cheers, >> -- Dan >> >> [1] http://hackage.haskell.org/package/lens >> [2] http://hackage.haskell.org/package/unamb >> [3] http://r6.ca/ >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 15:04:58 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 17:04:58 +0200 Subject: Buildbots In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the > options. But it depends on a critical evaluation of what the advantages and > disadvantages of different approaches are I found Ian's buildbot an appealing alternative as it does a full build, including testing, and uploads the resulting binaries to a common place where anybody can access them (but it can be configured to do almost anything). The builders may be configured individually from a single (Haskell-language) configuration file and they are run on various volunteer-supplied systems so it is also distributed. I use this to keep track of the status of the FreeBSD builds to make my work easier on building the releases and maintaining the associated ports in the FreeBSD Ports Collection, while offering regular developer snapshots for the users. This approach also allows me to control and maintain the builder environment too as it may require minor or major changes and fixes over time that I can do myself as a FreeBSD developer. In the past, there were cases where the build was failing due to bugs in the kernel or the userland, so this is not purely about GHC itself (unfortunately). In my humble opinon, there are merits for the Travis-based Continuous Integration, so as for the daily snapshot building on each supported platform. I do not care if it is not Haskell-based or it is hosted at a central place with individual Virtual Machines for each platform -- until I can keep doing what I have been doing for 4 years now. From dagitj at gmail.com Tue Apr 1 15:37:06 2014 From: dagitj at gmail.com (Jason Dagit) Date: Tue, 1 Apr 2014 08:37:06 -0700 Subject: New GHC Features for 7.10.1 and Beyond In-Reply-To: <533A426C.5070108@gmail.com> References: <533A426C.5070108@gmail.com> Message-ID: On Mon, Mar 31, 2014 at 9:37 PM, Gershom Bazerman wrote: > There's been lots of exciting work going into the forthcoming GHC 7.8.1 > release. But even with all these new features, our language is far from > complete and I wouldn't want the GHC team to rest on their laurels. > Especially with so much renewed community involvement in GHC development, > it seems appropriate to share some ideas some of us have been discussing > for future releases, and take a poll of community consensus regarding which > ones people might be excited to jump in and help out with, or might find > particularly helpful. > Thanks Gershom! I was going to wait till things were more mature before announcing them, but given the enthusiasm generated by your post I think I'll share what we've been working on early. Given the importance of BigData in today's business world and the complexities of writing software to support it, we have started working on an extension to Haskell to make BigData the language of choice for BigData applications. The first hurdle we face is how to represent BigData. Previously, we could work with the data but not give it a consistent or unified type. The data was simply too large! To make the representation as natural and manageable as possible we have introduced -XBigTypes. Note: For technical reasons this also implies -XImpredicativeTypes and allows construction of infinite types. With these sorts of restrictions lifted we are able to construct much larger types than before such as the type of all types and the type a such that `a = [a]`. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 1 17:45:27 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 13:45:27 -0400 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: hey all, I just exported the igloo builder code from darcs to git, and put it here https://github.com/cartazio/ghc-builder would this be something worth adding to github.com/haskell ? (i can easily add it if other folks it should be surfaced more visibly) On Tue, Apr 1, 2014 at 11:04 AM, P?li G?bor J?nos wrote: > 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : > > Indeed, there is no reason not to use Ian et al's Builder stuff. It's > one of the > > options. But it depends on a critical evaluation of what the advantages > and > > disadvantages of different approaches are > > I found Ian's buildbot an appealing alternative as it does a full > build, including testing, and uploads the resulting binaries to a > common place where anybody can access them (but it can be configured > to do almost anything). The builders may be configured individually > from a single (Haskell-language) configuration file and they are run > on various volunteer-supplied systems so it is also distributed. > > I use this to keep track of the status of the FreeBSD builds to make > my work easier on building the releases and maintaining the associated > ports in the FreeBSD Ports Collection, while offering regular > developer snapshots for the users. This approach also allows me to > control and maintain the builder environment too as it may require > minor or major changes and fixes over time that I can do myself as a > FreeBSD developer. In the past, there were cases where the build was > failing due to bugs in the kernel or the userland, so this is not > purely about GHC itself (unfortunately). > > In my humble opinon, there are merits for the Travis-based Continuous > Integration, so as for the daily snapshot building on each supported > platform. I do not care if it is not Haskell-based or it is hosted at > a central place with individual Virtual Machines for each platform -- > until I can keep doing what I have been doing for 4 years now. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.odea at gmail.com Tue Apr 1 18:15:12 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Tue, 1 Apr 2014 18:15:12 +0000 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Thank you Carter. I think it's reasonable to incubate it on your Github profile for now until we are certain it is fully working again. Either way works though :) Best, Alain > On Apr 1, 2014, at 17:45, Carter Schonwald wrote: > > hey all, I just exported the igloo builder code from darcs to git, and put it here https://github.com/cartazio/ghc-builder > would this be something worth adding to github.com/haskell ? (i can easily add it if other folks it should be surfaced more visibly) > > >> On Tue, Apr 1, 2014 at 11:04 AM, P?li G?bor J?nos wrote: >> 2014-04-01 14:03 GMT+02:00 Simon Peyton Jones : >> > Indeed, there is no reason not to use Ian et al's Builder stuff. It's one of the >> > options. But it depends on a critical evaluation of what the advantages and >> > disadvantages of different approaches are >> >> I found Ian's buildbot an appealing alternative as it does a full >> build, including testing, and uploads the resulting binaries to a >> common place where anybody can access them (but it can be configured >> to do almost anything). The builders may be configured individually >> from a single (Haskell-language) configuration file and they are run >> on various volunteer-supplied systems so it is also distributed. >> >> I use this to keep track of the status of the FreeBSD builds to make >> my work easier on building the releases and maintaining the associated >> ports in the FreeBSD Ports Collection, while offering regular >> developer snapshots for the users. This approach also allows me to >> control and maintain the builder environment too as it may require >> minor or major changes and fixes over time that I can do myself as a >> FreeBSD developer. In the past, there were cases where the build was >> failing due to bugs in the kernel or the userland, so this is not >> purely about GHC itself (unfortunately). >> >> In my humble opinon, there are merits for the Travis-based Continuous >> Integration, so as for the daily snapshot building on each supported >> platform. I do not care if it is not Haskell-based or it is hosted at >> a central place with individual Virtual Machines for each platform -- >> until I can keep doing what I have been doing for 4 years now. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 18:45:30 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 20:45:30 +0200 Subject: Buildbots In-Reply-To: <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: 2014-04-01 20:15 GMT+02:00 Alain O'Dea : > until we are certain it is fully working again. In what sense? I have been using the latest checkout from the darcs repository for both the server and the clients, I seldom experienced any serious problems. Of course, there is place for improvements and there are some rough edges, but I think it is quite usable, even in its current state. From carter.schonwald at gmail.com Tue Apr 1 18:50:06 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 1 Apr 2014 14:50:06 -0400 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: good to know (i assumed it was in working order from your remarks) I think making it more surfaced / discoverable might enable a lot more volunteer build bots (which is an issue aside from maintaining it) of course, officially moving it to github should be with ian's blessing, its mostly his work afaik :) On Tue, Apr 1, 2014 at 2:45 PM, P?li G?bor J?nos wrote: > 2014-04-01 20:15 GMT+02:00 Alain O'Dea : > > until we are certain it is fully working again. > > In what sense? I have been using the latest checkout from the darcs > repository for both the server and the clients, I seldom experienced > any serious problems. Of course, there is place for improvements and > there are some rough edges, but I think it is quite usable, even in > its current state. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Tue Apr 1 19:02:20 2014 From: dan.doel at gmail.com (Dan Doel) Date: Tue, 1 Apr 2014 15:02:20 -0400 Subject: Bang Patterns Message-ID: Greetings, I've been thinking about bang patterns as part of implementing our own Haskell-like compiler here, and have been testing out GHC's implementation to see how it works. I've come to one case that seems like it doesn't work how I think it should, or how it is described, and wanted to ask about it. Specifically, consider: case Nothing of !(~(Just x)) -> 5 Nothing -> 12 Now, the way I'd expect this to work, and how I think the spec says it works, is that my Nothing is evaluated, and then the irrefutable ~(Just x) matches Nothing, giving a result of 5. In fact, GHC warns about overlapping patterns for this. However, this actually evaluates to 12, meaning that !(~p) appears to cancel out and be equivalent to p. It seems to me this might be a side effect of the logic used to implement 'let !p = ...', but I'm not certain. So, my question is whether this is intentional. If it is, then the bang patterns description should probably mention it, since it's subtly different than the rest of the specification. Also the warning should be removed, because there is no overlapping in the above case statement. If it is unintentional, we should probably decide either to make it intentional (and perform the above changes), or to change the implementation. :) Cheers, -- Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Tue Apr 1 19:03:31 2014 From: pali.gabor at gmail.com (=?ISO-8859-1?Q?P=E1li_G=E1bor_J=E1nos?=) Date: Tue, 1 Apr 2014 21:03:31 +0200 Subject: Buildbots In-Reply-To: References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> <1396350664.2683.17.camel@kirk> <533AA6F6.1090309@centrum.cz> <618BE556AADD624C9C918AA5D5911BEF0D3795@DB3PRD3001MB020.064d.mgd.msft.net> <797E0B6F-7130-4592-A9A6-E03CBE980871@gmail.com> Message-ID: 2014-04-01 20:50 GMT+02:00 Carter Schonwald : > I think making it more surfaced / discoverable might enable a lot more > volunteer build bots (which is an issue aside from maintaining it) As Karel has indicated, I have been already running an instance of the server and I am generally open to adding further clients, if you think this would be useful. Perhaps the only limitation would be the disk space for storing all the snapshots builds for all the all clients, but I could easily solve this problem :-) Or, if you want to move the whole service to some more official place, e.g. under the haskell.org infrastructure, I am happy to help with restarting the service, I already earned some experience in running both sides over the years. From johan.tibell at gmail.com Tue Apr 1 19:07:47 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 1 Apr 2014 21:07:47 +0200 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: On Tue, Apr 1, 2014 at 12:46 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 01.04.2014, 10:25 +0000 schrieb Simon Peyton Jones: > > Joachim Breitner has set up Travis-CI. (I don't know exactly what > > that is, but it sounds useful.) > > Travis is a free cloud service that runs arbitrary tests (in our case, a > stripped version of validate) upon pushes to git repositories on github. > I set it up to validate our master, so we get a nice history of > successes and failures on > https://travis-ci.org/nomeata/ghc-complete/builds > and I get mails when things fail; that is when I send hopefully polite > enough mails to ghc-dev, asking people to fix their commits. > > (Unless I broke it myself; then I silently fix it and hide.) > If the false positive rate is low, feel free to automatically have the emails sent to ghc-devs at . We want to know when we broke stuff ASAP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igloo at earth.li Tue Apr 1 19:09:08 2014 From: igloo at earth.li (Ian Lynagh) Date: Tue, 1 Apr 2014 20:09:08 +0100 Subject: Buildbots In-Reply-To: <1396349165.2683.14.camel@kirk> References: <1396338146446-5746770.post@n5.nabble.com> <618BE556AADD624C9C918AA5D5911BEF0CE681@DB3PRD3001MB020.064d.mgd.msft.net> <1396349165.2683.14.camel@kirk> Message-ID: <20140401190908.GA2827@matrix.chaos.earth.li> On Tue, Apr 01, 2014 at 12:46:05PM +0200, Joachim Breitner wrote: > > happy with buildbot, it might not be the worst choice. For reference, the reason we moved away from buildbot is that it needs to maintain a TCP connection for the duration of the build. With some builds taking many hours (either on old platforms, or on modern hardware but with a full testsuite run and nofib etc) it was common that a brief network glitch caused a build to not finish. Thanks Ian From jwlato at gmail.com Tue Apr 1 21:26:39 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 14:26:39 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: Hi Edward, Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). And if somebody were to suggest that on a different day, +1 from me. John On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: > John, > > Check the date and consider the process necessary to "enumerate all > Haskell programs and check their types". > > -Edward > > > On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: > >> I think this is a great idea and should become a top priority. I would >> probably start by switching to a type-class-based seq, after which perhaps >> the next step forward would become more clear. >> >> John L. >> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >> >>> In the past year or two, there have been multiple performance problems >>> in >>> various areas related to the fact that lambda abstraction is not free, >>> though we >>> tend to think of it as so. A major example of this was deriving of >>> Functor. If we >>> were to derive Functor for lists, we would end up with something like: >>> >>> instance Functor [] where >>> fmap _ [] = [] >>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>> >>> This definition is O(n^2) when fully evaluated,, because it causes O(n) >>> eta >>> expansions of f, so we spend time following indirections proportional to >>> the >>> depth of the element in the list. This has been fixed in 7.8, but there >>> are >>> other examples. I believe lens, [1] for instance, has some stuff in it >>> that >>> works very hard to avoid this sort of cost; and it's not always as easy >>> to avoid >>> as the above example. Composing with a newtype wrapper, for instance, >>> causes an >>> eta expansion that can only be seen as such at the core level. >>> >>> The obvious solution is: do eta reduction. However, this is not >>> operationally >>> sound currently. The problem is that seq is capable of telling the >>> difference >>> between the following two expressions: >>> >>> undefined >>> \x -> undefined x >>> >>> The former causes seq to throw an exception, while the latter is >>> considered >>> defined enough to not do so. So, if we eta reduce, we can cause >>> terminating >>> programs to diverge if they make use of this feature. >>> >>> Luckily, there is a solution. >>> >>> Semantically one would usually identify the above two expressions. While >>> I do >>> believe one could construct a semantics that does distinguish them, it >>> is not >>> the usual practice. This suggests that there is a way to not distinguish >>> them, >>> perhaps even including seq. After all, the specification of seq is >>> monotone and >>> continuous regardless of whether we unify ? with \x -> ? x or insert an >>> extra >>> element for the latter. >>> >>> The currently problematic case is function spaces, so I'll focus on it. >>> How >>> should: >>> >>> seq : (a -> b) -> c -> c >>> >>> act? Well, other than an obvious bottom, we need to emit bottom whenever >>> our >>> given function is itself bottom at every input. This may first seem like >>> a >>> problem, but it is actually quite simple. Without loss of generality, >>> let us >>> assume that we can enumerate the type a. Then, we can feed these values >>> to the >>> function, and check their results for bottom. Conal Elliot has prior art >>> for >>> this sort of thing with his unamb [2] package. For each value x :: a, >>> simply >>> compute 'f x `seq` ()' in parallel, and look for any successes. If we >>> ever find >>> one, we know the function is non-bottom, and we can return our value of >>> c. If we >>> never finish searching, then the function must be bottom, and seq should >>> not >>> terminate, so we have satisfied the specification. >>> >>> Now, some may complain about the enumeration above. But this, too, is a >>> simple >>> matter. It is well known that Haskell programs are denumerable. So it is >>> quite >>> easy to enumerate all Haskell programs that produce a value, check >>> whether that >>> value has the type we're interested in, and compute said value. All of >>> this can >>> be done in Haskell. Thus, every Haskell type is programatically >>> enumerable in >>> Haskell, and we can use said enumeration in our implementation of seq for >>> function types. I have discussed this with Russell O'Connor [3], and he >>> assures >>> me that this argument should be sufficient even if we consider semantic >>> models >>> of Haskell that contain values not denoted by any Haskell program, so we >>> should >>> be safe there. >>> >>> The one possible caveat is that this implementation of seq is not >>> operationally >>> uniform across all types, so the current fully polymorphic type of seq >>> may not >>> make sense. But moving back to a type class based approach isn't so bad, >>> and >>> this time we will have a semantically sound backing, instead of just >>> having a >>> class with the equivalent of the current magic function in it. >>> >>> Once this machinery is in place, we can eta reduce to our hearts' >>> content, and >>> not have to worry about breaking semantics. We'd no longer put the >>> burden on >>> programmers to use potentially unsafe hacks to avoid eta expansions. I >>> apologize >>> for not sketching an implementation of the above algorithm, but I'm sure >>> it >>> should be elementary enough to make it into GHC in the next couple >>> versions. >>> Everyone learns about this type of thing in university computer science >>> programs, no? >>> >>> Thoughts? Comments? Questions? >>> >>> Cheers, >>> -- Dan >>> >>> [1] http://hackage.haskell.org/package/lens >>> [2] http://hackage.haskell.org/package/unamb >>> [3] http://r6.ca/ >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Apr 1 21:32:45 2014 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 1 Apr 2014 17:32:45 -0400 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: References: Message-ID: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> Unfortunately the old class based solution also carries other baggage, like the old data type contexts being needed in the language for bang patterns. :( -Edward > On Apr 1, 2014, at 5:26 PM, John Lato wrote: > > Hi Edward, > > Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). > > And if somebody were to suggest that on a different day, +1 from me. > > John > >> On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: >> John, >> >> Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". >> >> -Edward >> >> >>> On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: >>> I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. >>> >>> John L. >>> >>>> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >>>> In the past year or two, there have been multiple performance problems in >>>> various areas related to the fact that lambda abstraction is not free, though we >>>> tend to think of it as so. A major example of this was deriving of Functor. If we >>>> were to derive Functor for lists, we would end up with something like: >>>> >>>> instance Functor [] where >>>> fmap _ [] = [] >>>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>>> >>>> This definition is O(n^2) when fully evaluated,, because it causes O(n) eta >>>> expansions of f, so we spend time following indirections proportional to the >>>> depth of the element in the list. This has been fixed in 7.8, but there are >>>> other examples. I believe lens, [1] for instance, has some stuff in it that >>>> works very hard to avoid this sort of cost; and it's not always as easy to avoid >>>> as the above example. Composing with a newtype wrapper, for instance, causes an >>>> eta expansion that can only be seen as such at the core level. >>>> >>>> The obvious solution is: do eta reduction. However, this is not operationally >>>> sound currently. The problem is that seq is capable of telling the difference >>>> between the following two expressions: >>>> >>>> undefined >>>> \x -> undefined x >>>> >>>> The former causes seq to throw an exception, while the latter is considered >>>> defined enough to not do so. So, if we eta reduce, we can cause terminating >>>> programs to diverge if they make use of this feature. >>>> >>>> Luckily, there is a solution. >>>> >>>> Semantically one would usually identify the above two expressions. While I do >>>> believe one could construct a semantics that does distinguish them, it is not >>>> the usual practice. This suggests that there is a way to not distinguish them, >>>> perhaps even including seq. After all, the specification of seq is monotone and >>>> continuous regardless of whether we unify ? with \x -> ? x or insert an extra >>>> element for the latter. >>>> >>>> The currently problematic case is function spaces, so I'll focus on it. How >>>> should: >>>> >>>> seq : (a -> b) -> c -> c >>>> >>>> act? Well, other than an obvious bottom, we need to emit bottom whenever our >>>> given function is itself bottom at every input. This may first seem like a >>>> problem, but it is actually quite simple. Without loss of generality, let us >>>> assume that we can enumerate the type a. Then, we can feed these values to the >>>> function, and check their results for bottom. Conal Elliot has prior art for >>>> this sort of thing with his unamb [2] package. For each value x :: a, simply >>>> compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find >>>> one, we know the function is non-bottom, and we can return our value of c. If we >>>> never finish searching, then the function must be bottom, and seq should not >>>> terminate, so we have satisfied the specification. >>>> >>>> Now, some may complain about the enumeration above. But this, too, is a simple >>>> matter. It is well known that Haskell programs are denumerable. So it is quite >>>> easy to enumerate all Haskell programs that produce a value, check whether that >>>> value has the type we're interested in, and compute said value. All of this can >>>> be done in Haskell. Thus, every Haskell type is programatically enumerable in >>>> Haskell, and we can use said enumeration in our implementation of seq for >>>> function types. I have discussed this with Russell O'Connor [3], and he assures >>>> me that this argument should be sufficient even if we consider semantic models >>>> of Haskell that contain values not denoted by any Haskell program, so we should >>>> be safe there. >>>> >>>> The one possible caveat is that this implementation of seq is not operationally >>>> uniform across all types, so the current fully polymorphic type of seq may not >>>> make sense. But moving back to a type class based approach isn't so bad, and >>>> this time we will have a semantically sound backing, instead of just having a >>>> class with the equivalent of the current magic function in it. >>>> >>>> Once this machinery is in place, we can eta reduce to our hearts' content, and >>>> not have to worry about breaking semantics. We'd no longer put the burden on >>>> programmers to use potentially unsafe hacks to avoid eta expansions. I apologize >>>> for not sketching an implementation of the above algorithm, but I'm sure it >>>> should be elementary enough to make it into GHC in the next couple versions. >>>> Everyone learns about this type of thing in university computer science >>>> programs, no? >>>> >>>> Thoughts? Comments? Questions? >>>> >>>> Cheers, >>>> -- Dan >>>> >>>> [1] http://hackage.haskell.org/package/lens >>>> [2] http://hackage.haskell.org/package/unamb >>>> [3] http://r6.ca/ >>>> >>>> >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users at haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Apr 2 03:39:39 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 1 Apr 2014 20:39:39 -0700 Subject: [Haskell-cafe] Eta Reduction In-Reply-To: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> References: <1F4EACDC-CFDC-4551-AF34-975955C7DD07@gmail.com> Message-ID: I'm already uneasy using bang patterns on polymorphic data because I don't know exactly what it will accomplish. Maybe it adds too much strictness? Not enough? Simply duplicates work? Perhaps it's acceptable to remove that feature entirely (although that may require adding extra strictness in a lot of other places). Alternatively, maybe it's enough to simply find a use for that good-for-nothing syntax we already have? On Apr 1, 2014 5:32 PM, "Edward Kmett" wrote: > > Unfortunately the old class based solution also carries other baggage, like the old data type contexts being needed in the language for bang patterns. :( > > -Edward > > On Apr 1, 2014, at 5:26 PM, John Lato wrote: > >> Hi Edward, >> >> Yes, I'm aware of that. However, I thought Dan's proposal especially droll given that changing seq to a class-based function would be sufficient to make eta-reduction sound, given appropriate instances (or lack thereof). Meaning we could leave the rest of the proposal unevaluated (lazily!). >> >> And if somebody were to suggest that on a different day, +1 from me. >> >> John >> >> On Apr 1, 2014 10:32 AM, "Edward Kmett" wrote: >>> >>> John, >>> >>> Check the date and consider the process necessary to "enumerate all Haskell programs and check their types". >>> >>> -Edward >>> >>> >>> On Tue, Apr 1, 2014 at 9:17 AM, John Lato wrote: >>>> >>>> I think this is a great idea and should become a top priority. I would probably start by switching to a type-class-based seq, after which perhaps the next step forward would become more clear. >>>> >>>> John L. >>>> >>>> On Apr 1, 2014 2:54 AM, "Dan Doel" wrote: >>>>> >>>>> In the past year or two, there have been multiple performance problems in >>>>> various areas related to the fact that lambda abstraction is not free, though we >>>>> tend to think of it as so. A major example of this was deriving of Functor. If we >>>>> were to derive Functor for lists, we would end up with something like: >>>>> >>>>> instance Functor [] where >>>>> fmap _ [] = [] >>>>> fmap f (x:xs) = f x : fmap (\y -> f y) xs >>>>> >>>>> This definition is O(n^2) when fully evaluated,, because it causes O(n) eta >>>>> expansions of f, so we spend time following indirections proportional to the >>>>> depth of the element in the list. This has been fixed in 7.8, but there are >>>>> other examples. I believe lens, [1] for instance, has some stuff in it that >>>>> works very hard to avoid this sort of cost; and it's not always as easy to avoid >>>>> as the above example. Composing with a newtype wrapper, for instance, causes an >>>>> eta expansion that can only be seen as such at the core level. >>>>> >>>>> The obvious solution is: do eta reduction. However, this is not operationally >>>>> sound currently. The problem is that seq is capable of telling the difference >>>>> between the following two expressions: >>>>> >>>>> undefined >>>>> \x -> undefined x >>>>> >>>>> The former causes seq to throw an exception, while the latter is considered >>>>> defined enough to not do so. So, if we eta reduce, we can cause terminating >>>>> programs to diverge if they make use of this feature. >>>>> >>>>> Luckily, there is a solution. >>>>> >>>>> Semantically one would usually identify the above two expressions. While I do >>>>> believe one could construct a semantics that does distinguish them, it is not >>>>> the usual practice. This suggests that there is a way to not distinguish them, >>>>> perhaps even including seq. After all, the specification of seq is monotone and >>>>> continuous regardless of whether we unify ? with \x -> ? x or insert an extra >>>>> element for the latter. >>>>> >>>>> The currently problematic case is function spaces, so I'll focus on it. How >>>>> should: >>>>> >>>>> seq : (a -> b) -> c -> c >>>>> >>>>> act? Well, other than an obvious bottom, we need to emit bottom whenever our >>>>> given function is itself bottom at every input. This may first seem like a >>>>> problem, but it is actually quite simple. Without loss of generality, let us >>>>> assume that we can enumerate the type a. Then, we can feed these values to the >>>>> function, and check their results for bottom. Conal Elliot has prior art for >>>>> this sort of thing with his unamb [2] package. For each value x :: a, simply >>>>> compute 'f x `seq` ()' in parallel, and look for any successes. If we ever find >>>>> one, we know the function is non-bottom, and we can return our value of c. If we >>>>> never finish searching, then the function must be bottom, and seq should not >>>>> terminate, so we have satisfied the specification. >>>>> >>>>> Now, some may complain about the enumeration above. But this, too, is a simple >>>>> matter. It is well known that Haskell programs are denumerable. So it is quite >>>>> easy to enumerate all Haskell programs that produce a value, check whether that >>>>> value has the type we're interested in, and compute said value. All of this can >>>>> be done in Haskell. Thus, every Haskell type is programatically enumerable in >>>>> Haskell, and we can use said enumeration in our implementation of seq for >>>>> function types. I have discussed this with Russell O'Connor [3], and he assures >>>>> me that this argument should be sufficient even if we consider semantic models >>>>> of Haskell that contain values not denoted by any Haskell program, so we should >>>>> be safe there. >>>>> >>>>> The one possible caveat is that this implementation of seq is not operationally >>>>> uniform across all types, so the current fully polymorphic type of seq may not >>>>> make sense. But moving back to a type class based approach isn't so bad, and >>>>> this time we will have a semantically sound backing, instead of just having a >>>>> class with the equivalent of the current magic function in it. >>>>> >>>>> Once this machinery is in place, we can eta reduce to our hearts' content, and >>>>> not have to worry about breaking semantics. We'd no longer put the burden on >>>>> programmers to use potentially unsafe hacks to avoid eta expansions. I apologize >>>>> for not sketching an implementation of the above algorithm, but I'm sure it >>>>> should be elementary enough to make it into GHC in the next couple versions. >>>>> Everyone learns about this type of thing in university computer science >>>>> programs, no? >>>>> >>>>> Thoughts? Comments? Questions? >>>>> >>>>> Cheers, >>>>> -- Dan >>>>> >>>>> [1] http://hackage.haskell.org/package/lens >>>>> [2] http://hackage.haskell.org/package/unamb >>>>> [3] http://r6.ca/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> Glasgow-haskell-users mailing list >>>>> Glasgow-haskell-users at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Wed Apr 2 19:41:29 2014 From: winterkoninkje at gmail.com (wren romano) Date: Wed, 2 Apr 2014 15:41:29 -0400 Subject: Bang Patterns In-Reply-To: References: Message-ID: On Tue, Apr 1, 2014 at 3:02 PM, Dan Doel wrote: > Specifically, consider: > > case Nothing of > !(~(Just x)) -> 5 > Nothing -> 12 > > Now, the way I'd expect this to work, and how I think the spec says it > works, is that my Nothing is evaluated, and then the irrefutable ~(Just x) > matches Nothing, giving a result of 5. In fact, GHC warns about overlapping > patterns for this. It's sensible to give an overlap warning --that is, assuming we don't want overlap to be an error-- since the irrefutable pattern matches everything, and adding bangs doesn't change what values are matched (it only changes whether we diverge or not). However, I have no idea how top-level bang in case-expressions is supposed to be interpreted. If anything, it should be ignored since we must already force the scrutinee to WHNF before matching *any* of the clauses of a case-expression. However, I thought bangs were restricted to (1) immediately before variables, and (2) for top-level use in let/where clauses... In any case, following the standard desugaring of the specs: case Nothing of !(~(Just x)) -> 5 ; Nothing -> 12 === { next to last box of , the proposed clause (t) for section 3.17.3, figure 4 } Nothing `seq` case Nothing of ~(Just x) -> 5 ; Nothing -> 12 === { Haskell Report, section 3.17.3, figure 3, clause (d) } Nothing `seq` (\x -> 5) (case Nothing of Just x -> x) Which most definitely does not evaluate to 12. Either the specs are wrong (dubious) or the implementation is. File a bug report. -- Live well, ~wren From dan.doel at gmail.com Thu Apr 3 03:10:30 2014 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 2 Apr 2014 23:10:30 -0400 Subject: Bang Patterns In-Reply-To: References: Message-ID: Filed. Bug #8952. On Wed, Apr 2, 2014 at 3:41 PM, wren romano wrote: > On Tue, Apr 1, 2014 at 3:02 PM, Dan Doel wrote: > > Specifically, consider: > > > > case Nothing of > > !(~(Just x)) -> 5 > > Nothing -> 12 > > > > Now, the way I'd expect this to work, and how I think the spec says it > > works, is that my Nothing is evaluated, and then the irrefutable ~(Just > x) > > matches Nothing, giving a result of 5. In fact, GHC warns about > overlapping > > patterns for this. > > It's sensible to give an overlap warning --that is, assuming we don't > want overlap to be an error-- since the irrefutable pattern matches > everything, and adding bangs doesn't change what values are matched > (it only changes whether we diverge or not). > > However, I have no idea how top-level bang in case-expressions is > supposed to be interpreted. If anything, it should be ignored since we > must already force the scrutinee to WHNF before matching *any* of the > clauses of a case-expression. However, I thought bangs were restricted > to (1) immediately before variables, and (2) for top-level use in > let/where clauses... > > In any case, following the standard desugaring of the specs: > > case Nothing of !(~(Just x)) -> 5 ; Nothing -> 12 > > === { next to last box of > < > http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html > >, > the proposed clause (t) for section 3.17.3, figure 4 } > > Nothing `seq` case Nothing of ~(Just x) -> 5 ; Nothing -> 12 > > === { Haskell Report, section 3.17.3, figure 3, clause (d) } > > Nothing `seq` (\x -> 5) (case Nothing of Just x -> x) > > Which most definitely does not evaluate to 12. Either the specs are > wrong (dubious) or the implementation is. File a bug report. > > -- > Live well, > ~wren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Fri Apr 4 08:02:14 2014 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Fri, 4 Apr 2014 10:02:14 +0200 Subject: GHC API: getting the unfolding of a "strange" Id In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0D358B@DB3PRD3001MB020.064d.mgd.msft.net> References: <642612DC-927B-43A8-9CD2-07BBD1B4D6B5@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0C6176@DB3PRD3001MB020.064d.mgd.msft.net> <214060E8-ABC4-4C8B-B6CC-91B0C0A304F4@gmail.com> <299206C2-6350-4B07-87C5-2FF3608E88A8@gmail.com> <618BE556AADD624C9C918AA5D5911BEF0D358B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <076FD86C-30B4-4D2B-A755-99791B3AE4A2@gmail.com> Thank you for the explanation, I think I pretty much understand what's going on now. Indeed, nothing went wrong, it was just that I thought that the flag -fexpose-all-unfoldings would indeed put _all_ unfoldings in the interface file: even unfoldings that are bottom values. For my use-case, I can just compile the file with -fno-strictness so that this top-level bottom value is never created in the first instance. Here are the -dverbose-core2core files: Compiled with no additional / default flags: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/noflags.core Compiled with -fexpose-all-unfoldings: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfoldings.core Compiled with -fexpose-all-unfoldings -fno-strictness: https://raw.githubusercontent.com/christiaanb/clash-prelude/gh-pages/allunfoldings_nostrictness.core -- Christiaan On Apr 1, 2014, at 1:11 PM, Simon Peyton Jones wrote: > These "absent" thunks appear when the strictness analyser works out that a function does not use an argument at all. Suppose 'f' does not use its first argument. Then a call > f (...big expression...) > will be replaced with > f (absentError "blah") > > Such thunks almost invariably turn out to be dead code in the end, and are discarded. It's very unusual for them to survive to the end of compilation, let alone as a top-level value. But it's not impossible. > > Just for curiosity, can you compile with -dverbose-core2core, and leave the results somewhere I can see them? > > In short, it doesn't look as if there is anything wrong. If there's a good reason you want to see the unfolding anyway, that's not impossible, but at least you understand what is happening now. > > Simon From austin at well-typed.com Wed Apr 9 14:10:34 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 9 Apr 2014 09:10:34 -0500 Subject: ANNOUNCE: GHC version 7.8.1 Message-ID: ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * New type-system features * Closed type families * Role checking * An improved solver for type naturals * Better support for cross compilation * Full iOS support * Massive scalability improvements to the I/O manager * Dynamic linking for GHCi * Several language improvements * Pattern synonyms * Overloaded list syntax * Kind-polymorphic 'Typeable' class * A new parallel --make mode * Preliminary SIMD intrinsic support * A brand-new low level code generator * Many bugfixes and other performance improvements. The full release notes are here: http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA256SUMS.sig Type: application/octet-stream Size: 836 bytes Desc: not available URL: From austin at well-typed.com Wed Apr 9 14:23:48 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 9 Apr 2014 09:23:48 -0500 Subject: ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: Hello all, A minor amedment: I accidentally named one of the tarballs slightly wrong. ghc-7.8.1-x86_64-apple-darwin-mountainlion.tar.bz2 should have been ghc-7.8.1-x86_64-apple-darwin-mavericks.tar.bz2, similarly with the .tar.xz. I simply forgot to rename it appropriately! The hashes have not changed. Lion builds will come soon too for users of 10.7 and such. An updated SHA256SUMS.sig is attached. Thanks for Edsko de Vries for pointing it out! On Wed, Apr 9, 2014 at 9:10 AM, Austin Seipp wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 > ============================================================== > > The GHC Team is pleased to announce a new major release of GHC. There > have been a number of significant changes since the last major release, > including: > > * New type-system features > * Closed type families > * Role checking > * An improved solver for type naturals > * Better support for cross compilation > * Full iOS support > * Massive scalability improvements to the I/O manager > * Dynamic linking for GHCi > * Several language improvements > * Pattern synonyms > * Overloaded list syntax > * Kind-polymorphic 'Typeable' class > * A new parallel --make mode > * Preliminary SIMD intrinsic support > * A brand-new low level code generator > * Many bugfixes and other performance improvements. > > The full release notes are here: > > http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-1.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/TeamGHC > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > Hashes & Signatures > ~~~~~~~~~~~~~~~~~ > > Included in this email is a signed copy of the SHA256 hashes for the > tarballs, using my GPG key (keyid 0x3B58D86F). > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA256SUMS.sig Type: application/octet-stream Size: 836 bytes Desc: not available URL: From djsamperi at gmail.com Wed Apr 9 15:23:42 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Wed, 9 Apr 2014 11:23:42 -0400 Subject: ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: Thank you Austin! I unpacked the Windows 64bit distribution and tried to update cabal as instructed, but got this: Registering zlib-0.5.4.1... cabal: Error: some packages failed to install: HTTP-4000.2.12 depends on network 2.4.2.2 which failed to install. network-2.4.2.2 failed during the configure step. On Wed, Apr 9, 2014 at 10:10 AM, Austin Seipp wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 > ============================================================== > > The GHC Team is pleased to announce a new major release of GHC. There > have been a number of significant changes since the last major release, > including: > > * New type-system features > * Closed type families > * Role checking > * An improved solver for type naturals > * Better support for cross compilation > * Full iOS support > * Massive scalability improvements to the I/O manager > * Dynamic linking for GHCi > * Several language improvements > * Pattern synonyms > * Overloaded list syntax > * Kind-polymorphic 'Typeable' class > * A new parallel --make mode > * Preliminary SIMD intrinsic support > * A brand-new low level code generator > * Many bugfixes and other performance improvements. > > The full release notes are here: > > http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-1.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/TeamGHC > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > Hashes & Signatures > ~~~~~~~~~~~~~~~~~ > > Included in this email is a signed copy of the SHA256 hashes for the > tarballs, using my GPG key (keyid 0x3B58D86F). > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From mikesteele81 at gmail.com Wed Apr 9 16:03:17 2014 From: mikesteele81 at gmail.com (Michael Steele) Date: Wed, 9 Apr 2014 09:03:17 -0700 Subject: ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: Dominick, I don't know what error you ran into, but here are a few tips: * The "network" package requires configure, so you will likely need to install it from an MSYS prompt. * Make sure your existing cabal executable is version 1.18 or higher. Execute `cabal --version` and `ghc --version` to make sure older versions are not being found. Because of the way Windows handles paths you may have to specify the full path to cabal.exe * Delete your %appdata%\ghc and %appdata%\cabal folders, then run `cabal update`. This will clear out any previous cabal packages you may have already installed. On Wed, Apr 9, 2014 at 8:23 AM, Dominick Samperi wrote: > Thank you Austin! > > I unpacked the Windows 64bit distribution and tried to update cabal as > instructed, but got this: > Registering zlib-0.5.4.1... > cabal: Error: some packages failed to install: > HTTP-4000.2.12 depends on network 2.4.2.2 which failed to install. > network-2.4.2.2 failed during the configure step. > > On Wed, Apr 9, 2014 at 10:10 AM, Austin Seipp > wrote: > > ============================================================== > > The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 > > ============================================================== > > > > The GHC Team is pleased to announce a new major release of GHC. There > > have been a number of significant changes since the last major release, > > including: > > > > * New type-system features > > * Closed type families > > * Role checking > > * An improved solver for type naturals > > * Better support for cross compilation > > * Full iOS support > > * Massive scalability improvements to the I/O manager > > * Dynamic linking for GHCi > > * Several language improvements > > * Pattern synonyms > > * Overloaded list syntax > > * Kind-polymorphic 'Typeable' class > > * A new parallel --make mode > > * Preliminary SIMD intrinsic support > > * A brand-new low level code generator > > * Many bugfixes and other performance improvements. > > > > The full release notes are here: > > > > http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-1.html > > > > How to get it > > ~~~~~~~~~~~~~ > > > > The easy way is to go to the web page, which should be self-explanatory: > > > > http://www.haskell.org/ghc/ > > > > We supply binary builds in the native package format for many > > platforms, and the source distribution is available from the same > > place. > > > > Packages will appear as they are built - if the package for your > > system isn't available yet, please try again later. > > > > > > Background > > ~~~~~~~~~~ > > > > Haskell is a standard lazy functional programming language. > > > > GHC is a state-of-the-art programming suite for Haskell. Included is > > an optimising compiler generating good code for a variety of > > platforms, together with an interactive system for convenient, quick > > development. The distribution includes space and time profiling > > facilities, a large collection of libraries, and support for various > > language extensions, including concurrency, exceptions, and foreign > > language interfaces (C, whatever). GHC is distributed under a > > BSD-style open source license. > > > > A wide variety of Haskell related resources (tutorials, libraries, > > specifications, documentation, compilers, interpreters, references, > > contact information, links to research groups) are available from the > > Haskell home page (see below). > > > > > > On-line GHC-related resources > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Relevant URLs on the World-Wide Web: > > > > GHC home page http://www.haskell.org/ghc/ > > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > > Haskell home page http://www.haskell.org/ > > > > > > Supported Platforms > > ~~~~~~~~~~~~~~~~~~~ > > > > The list of platforms we support, and the people responsible for them, > > is here: > > > > http://ghc.haskell.org/trac/ghc/wiki/TeamGHC > > > > Ports to other platforms are possible with varying degrees of > > difficulty. The Building Guide describes how to go about porting to a > > new platform: > > > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > > > > Developers > > ~~~~~~~~~~ > > > > We welcome new contributors. Instructions on accessing our source > > code repository, and getting started with hacking on GHC, are > > available from the GHC's developer's site run by Trac: > > > > http://ghc.haskell.org/trac/ghc/ > > > > > > Mailing lists > > ~~~~~~~~~~~~~ > > > > We run mailing lists for GHC users and bug reports; to subscribe, use > > the web interfaces at > > > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > > There are several other haskell and ghc-related mailing lists on > > www.haskell.org; for the full list, see > > > > http://www.haskell.org/mailman/listinfo/ > > > > Some GHC developers hang out on #haskell on IRC, too: > > > > http://www.haskell.org/haskellwiki/IRC_channel > > > > Please report bugs using our bug tracking system. Instructions on > > reporting bugs can be found here: > > > > http://www.haskell.org/ghc/reportabug > > > > Hashes & Signatures > > ~~~~~~~~~~~~~~~~~ > > > > Included in this email is a signed copy of the SHA256 hashes for the > > tarballs, using my GPG key (keyid 0x3B58D86F). > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Wed Apr 9 17:24:28 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed, 09 Apr 2014 14:24:28 -0300 Subject: ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: <5345824C.2050203@gmail.com> Em 09-04-2014 11:23, Austin Seipp escreveu: > An updated SHA256SUMS.sig is attached. Thanks for Edsko de Vries for > pointing it out! If anybody is, like myself, trying to find a link for the SHA256SUMS file on the download page, here it is: https://www.haskell.org/ghc/dist/7.8.1/SHA256SUMS For some reason it seems that it's not linked anywhere on that page. Cheers, and thanks for the release! =) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From conal at conal.net Wed Apr 9 17:46:39 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 9 Apr 2014 10:46:39 -0700 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' Message-ID: I installed the binary distribution of GHC 7.8.1 for Mac OS this morning, cabal-installed a few packages, and now I get a *lot* of warnings about missing .haddock files: bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory ... Expected behavior? Avoidable? Fixable? Thanks, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Apr 9 17:53:47 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 9 Apr 2014 10:53:47 -0700 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' In-Reply-To: References: Message-ID: >From a bit of experimentation, it appears that the problematic packages do indeed have Haddock failures. For instance, bash-3.2$ cd random-1.0.1.1/ bash-3.2$ cabal configure Resolving dependencies... Configuring random-1.0.1.1... bash-3.2$ cabal haddock Running Haddock for random-1.0.1.1... Preprocessing library random-1.0.1.1... Haddock coverage: System/Random.hs:2:2: parse error on input '#' On Wed, Apr 9, 2014 at 10:46 AM, Conal Elliott wrote: > I installed the binary distribution of GHC 7.8.1 for Mac OS this morning, > cabal-installed a few packages, and now I get a *lot* of warnings about > missing .haddock files: > > bash-3.2$ ghc-pkg check > Warning: haddock-interfaces: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock > doesn't exist or isn't a file > Warning: haddock-interfaces: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock > doesn't exist or isn't a file > Warning: haddock-interfaces: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock > doesn't exist or isn't a file > Warning: haddock-interfaces: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock > doesn't exist or isn't a file > Warning: haddock-html: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html > doesn't exist or isn't a directory > Warning: haddock-interfaces: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock > doesn't exist or isn't a file > Warning: haddock-html: > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't > exist or isn't a directory > ... > > Expected behavior? Avoidable? Fixable? > > Thanks, - Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Apr 9 18:07:49 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 9 Apr 2014 11:07:49 -0700 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' In-Reply-To: References: Message-ID: My concern about the volume of warnings here is that it distracts from the info I'm after, namely broken packages. One coping strategy seems to be using the --simple-output flag to 'ghc-pkg check'. In that case, the haddock warnings are suppressed, and I see just a list of broken package names. A little terser than I'm after, but it helps. On Wed, Apr 9, 2014 at 10:53 AM, Conal Elliott wrote: > From a bit of experimentation, it appears that the problematic packages do > indeed have Haddock failures. For instance, > > bash-3.2$ cd random-1.0.1.1/ > bash-3.2$ cabal configure > Resolving dependencies... > Configuring random-1.0.1.1... > bash-3.2$ cabal haddock > Running Haddock for random-1.0.1.1... > Preprocessing library random-1.0.1.1... > Haddock coverage: > > System/Random.hs:2:2: parse error on input '#' > > > > > On Wed, Apr 9, 2014 at 10:46 AM, Conal Elliott wrote: > >> I installed the binary distribution of GHC 7.8.1 for Mac OS this morning, >> cabal-installed a few packages, and now I get a *lot* of warnings about >> missing .haddock files: >> >> bash-3.2$ ghc-pkg check >> Warning: haddock-interfaces: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock >> doesn't exist or isn't a file >> Warning: haddock-interfaces: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock >> doesn't exist or isn't a file >> Warning: haddock-interfaces: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock >> doesn't exist or isn't a file >> Warning: haddock-interfaces: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock >> doesn't exist or isn't a file >> Warning: haddock-html: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html >> doesn't exist or isn't a directory >> Warning: haddock-interfaces: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock >> doesn't exist or isn't a file >> Warning: haddock-html: >> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't >> exist or isn't a directory >> ... >> >> Expected behavior? Avoidable? Fixable? >> >> Thanks, - Conal >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Wed Apr 9 19:12:17 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Wed, 9 Apr 2014 15:12:17 -0400 Subject: ANNOUNCE: GHC version 7.8.1 In-Reply-To: References: Message-ID: Thank you Michael, It is not clear how to install the latest cabal under Windows. Apparently cabal cannot install itself (cabal install cabal), so I tried simply downloading cabal.exe from the cabal site and placing it in my path. cabal --version shows the correct version (1.18), but when I try 'cabal install cabal-install' I get: setup-Cabal-1.18.1.3_x86_64-windows-ghc-7.8.1.exe: does not exist MSYS did fix the configure issues with network (before I updated cabal as above), and I did clear out my old cabal and ghc folders. Thanks, Dominick On Wed, Apr 9, 2014 at 12:03 PM, Michael Steele wrote: > Dominick, > > I don't know what error you ran into, but here are a few tips: > > * The "network" package requires configure, so you will likely need to > install it from an MSYS prompt. > > * Make sure your existing cabal executable is version 1.18 or higher. > Execute `cabal --version` and `ghc --version` to make sure older versions > are not being found. Because of the way Windows handles paths you may have > to specify the full path to cabal.exe > > * Delete your %appdata%\ghc and %appdata%\cabal folders, then run `cabal > update`. This will clear out any previous cabal packages you may have > already installed. > > > On Wed, Apr 9, 2014 at 8:23 AM, Dominick Samperi > wrote: >> >> Thank you Austin! >> >> I unpacked the Windows 64bit distribution and tried to update cabal as >> instructed, but got this: >> Registering zlib-0.5.4.1... >> cabal: Error: some packages failed to install: >> HTTP-4000.2.12 depends on network 2.4.2.2 which failed to install. >> network-2.4.2.2 failed during the configure step. >> >> On Wed, Apr 9, 2014 at 10:10 AM, Austin Seipp >> wrote: >> > ============================================================== >> > The (Interactive) Glasgow Haskell Compiler -- version 7.8.1 >> > ============================================================== >> > >> > The GHC Team is pleased to announce a new major release of GHC. There >> > have been a number of significant changes since the last major release, >> > including: >> > >> > * New type-system features >> > * Closed type families >> > * Role checking >> > * An improved solver for type naturals >> > * Better support for cross compilation >> > * Full iOS support >> > * Massive scalability improvements to the I/O manager >> > * Dynamic linking for GHCi >> > * Several language improvements >> > * Pattern synonyms >> > * Overloaded list syntax >> > * Kind-polymorphic 'Typeable' class >> > * A new parallel --make mode >> > * Preliminary SIMD intrinsic support >> > * A brand-new low level code generator >> > * Many bugfixes and other performance improvements. >> > >> > The full release notes are here: >> > >> > http://haskell.org/ghc/docs/7.8.1/html/users_guide/release-7-8-1.html >> > >> > How to get it >> > ~~~~~~~~~~~~~ >> > >> > The easy way is to go to the web page, which should be self-explanatory: >> > >> > http://www.haskell.org/ghc/ >> > >> > We supply binary builds in the native package format for many >> > platforms, and the source distribution is available from the same >> > place. >> > >> > Packages will appear as they are built - if the package for your >> > system isn't available yet, please try again later. >> > >> > >> > Background >> > ~~~~~~~~~~ >> > >> > Haskell is a standard lazy functional programming language. >> > >> > GHC is a state-of-the-art programming suite for Haskell. Included is >> > an optimising compiler generating good code for a variety of >> > platforms, together with an interactive system for convenient, quick >> > development. The distribution includes space and time profiling >> > facilities, a large collection of libraries, and support for various >> > language extensions, including concurrency, exceptions, and foreign >> > language interfaces (C, whatever). GHC is distributed under a >> > BSD-style open source license. >> > >> > A wide variety of Haskell related resources (tutorials, libraries, >> > specifications, documentation, compilers, interpreters, references, >> > contact information, links to research groups) are available from the >> > Haskell home page (see below). >> > >> > >> > On-line GHC-related resources >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> > Relevant URLs on the World-Wide Web: >> > >> > GHC home page http://www.haskell.org/ghc/ >> > GHC developers' home page http://ghc.haskell.org/trac/ghc/ >> > Haskell home page http://www.haskell.org/ >> > >> > >> > Supported Platforms >> > ~~~~~~~~~~~~~~~~~~~ >> > >> > The list of platforms we support, and the people responsible for them, >> > is here: >> > >> > http://ghc.haskell.org/trac/ghc/wiki/TeamGHC >> > >> > Ports to other platforms are possible with varying degrees of >> > difficulty. The Building Guide describes how to go about porting to a >> > new platform: >> > >> > http://ghc.haskell.org/trac/ghc/wiki/Building >> > >> > >> > Developers >> > ~~~~~~~~~~ >> > >> > We welcome new contributors. Instructions on accessing our source >> > code repository, and getting started with hacking on GHC, are >> > available from the GHC's developer's site run by Trac: >> > >> > http://ghc.haskell.org/trac/ghc/ >> > >> > >> > Mailing lists >> > ~~~~~~~~~~~~~ >> > >> > We run mailing lists for GHC users and bug reports; to subscribe, use >> > the web interfaces at >> > >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> > >> > There are several other haskell and ghc-related mailing lists on >> > www.haskell.org; for the full list, see >> > >> > http://www.haskell.org/mailman/listinfo/ >> > >> > Some GHC developers hang out on #haskell on IRC, too: >> > >> > http://www.haskell.org/haskellwiki/IRC_channel >> > >> > Please report bugs using our bug tracking system. Instructions on >> > reporting bugs can be found here: >> > >> > http://www.haskell.org/ghc/reportabug >> > >> > Hashes & Signatures >> > ~~~~~~~~~~~~~~~~~ >> > >> > Included in this email is a signed copy of the SHA256 hashes for the >> > tarballs, using my GPG key (keyid 0x3B58D86F). >> > >> > -- >> > Regards, >> > >> > Austin Seipp, Haskell Consultant >> > Well-Typed LLP, http://www.well-typed.com/ >> > >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > -- > -- Michael Steele From austin at well-typed.com Thu Apr 10 01:16:10 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 9 Apr 2014 20:16:10 -0500 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' In-Reply-To: References: Message-ID: Hi Conal, Damn, I think I somehow totally missed this. :( I'll look into on my Mavericks machine and see what's going wrong - I figured ./validate would have caught this, but perhaps something strange is going on. I filed a bug for you marked for 7.8.2: https://ghc.haskell.org/trac/ghc/ticket/8981 On Wed, Apr 9, 2014 at 1:07 PM, Conal Elliott wrote: > My concern about the volume of warnings here is that it distracts from the > info I'm after, namely broken packages. One coping strategy seems to be > using the --simple-output flag to 'ghc-pkg check'. In that case, the haddock > warnings are suppressed, and I see just a list of broken package names. A > little terser than I'm after, but it helps. > > > On Wed, Apr 9, 2014 at 10:53 AM, Conal Elliott wrote: >> >> From a bit of experimentation, it appears that the problematic packages do >> indeed have Haddock failures. For instance, >> >> bash-3.2$ cd random-1.0.1.1/ >> bash-3.2$ cabal configure >> Resolving dependencies... >> Configuring random-1.0.1.1... >> bash-3.2$ cabal haddock >> Running Haddock for random-1.0.1.1... >> Preprocessing library random-1.0.1.1... >> Haddock coverage: >> >> System/Random.hs:2:2: parse error on input ?#? >> >> >> >> >> On Wed, Apr 9, 2014 at 10:46 AM, Conal Elliott wrote: >>> >>> I installed the binary distribution of GHC 7.8.1 for Mac OS this morning, >>> cabal-installed a few packages, and now I get a *lot* of warnings about >>> missing .haddock files: >>> >>> bash-3.2$ ghc-pkg check >>> Warning: haddock-interfaces: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock >>> doesn't exist or isn't a file >>> Warning: haddock-interfaces: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock >>> doesn't exist or isn't a file >>> Warning: haddock-interfaces: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock >>> doesn't exist or isn't a file >>> Warning: haddock-interfaces: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock >>> doesn't exist or isn't a file >>> Warning: haddock-html: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html >>> doesn't exist or isn't a directory >>> Warning: haddock-interfaces: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock >>> doesn't exist or isn't a file >>> Warning: haddock-html: >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't >>> exist or isn't a directory >>> ... >>> >>> Expected behavior? Avoidable? Fixable? >>> >>> Thanks, - Conal >> >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From haskell.vivian.mcphail at gmail.com Thu Apr 10 03:24:44 2014 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Thu, 10 Apr 2014 15:24:44 +1200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails Message-ID: Hi, Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following: # cabal install --global vector ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.2.1 ... : can't load .so/.DLL for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open shared object file: No such file or directory) cabal: Error: some packages failed to install: vector-0.10.9.1 failed during the building phase. The exception was: ExitFailure 1 Cheers, Vivian -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Apr 10 03:42:26 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 9 Apr 2014 23:42:26 -0400 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: References: Message-ID: i bet you have cabal --version reply with 1.16 :) 1) cabal update 2) cabal install cabal-install 3) rm ~/.cabal/config # old pre 1.18 config should go! 4) cabal update # also probably add ~/.cabal/bin to path 5) cabal install vector On Wed, Apr 9, 2014 at 11:24 PM, Vivian McPhail < haskell.vivian.mcphail at gmail.com> wrote: > Hi, > > Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following: > > # cabal install --global vector > ... > [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( > Data/Vector/Fusion/Stream/Monadic.hs, > dist/build/Data/Vector/Fusion/Stream/Monadic.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package primitive-0.5.2.1 ... : can't load .so/.DLL > for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open > shared object file: No such file or directory) > cabal: Error: some packages failed to install: > vector-0.10.9.1 failed during the building phase. The exception was: > ExitFailure 1 > > Cheers, > > Vivian > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell.vivian.mcphail at gmail.com Thu Apr 10 04:00:43 2014 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Thu, 10 Apr 2014 16:00:43 +1200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: References: Message-ID: Indeed. It was using the wrong cabal-install version. Even though I had installed the newest cabal-install I needed to restart the xterm I was working in. Thanks, Vivian On 10 April 2014 15:42, Carter Schonwald wrote: > i bet you have cabal --version reply with 1.16 :) > > 1) cabal update > 2) cabal install cabal-install > 3) rm ~/.cabal/config # old pre 1.18 config should go! > 4) cabal update # also probably add ~/.cabal/bin to path > 5) cabal install vector > > > > On Wed, Apr 9, 2014 at 11:24 PM, Vivian McPhail < > haskell.vivian.mcphail at gmail.com> wrote: > >> Hi, >> >> Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following: >> >> # cabal install --global vector >> ... >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( >> Data/Vector/Fusion/Stream/Monadic.hs, >> dist/build/Data/Vector/Fusion/Stream/Monadic.o ) >> Loading package ghc-prim ... linking ... done. >> Loading package integer-gmp ... linking ... done. >> Loading package base ... linking ... done. >> Loading package primitive-0.5.2.1 ... : can't load .so/.DLL >> for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open >> shared object file: No such file or directory) >> cabal: Error: some packages failed to install: >> vector-0.10.9.1 failed during the building phase. The exception was: >> ExitFailure 1 >> >> Cheers, >> >> Vivian >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Thu Apr 10 06:34:01 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 10 Apr 2014 15:34:01 +0900 (JST) Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.8.1 In-Reply-To: <87d2gp4s7n.fsf@wespe.malde.org> References: <87d2gp4s7n.fsf@wespe.malde.org> Message-ID: <20140410.153401.127913868145496843.kazu@iij.ad.jp> >> * Massive scalability improvements to the I/O manager > > Just a brief note from the front lines - I recompiled a heavily threaded > program with (a recent pre-release) of 7.8.1 and got a 10% performance > increase over 7.6.3. Nothing like free lunches - so thanks again for > the great work! Did you run you program on a multicore system? If so, did you specify +RTS -N option? If your program uses MVar heavily, you need to re-design your program. For more information, please read: http://www.yesodweb.com/blog/2014/01/new-fast-logger --Kazu From daniel.is.fischer at googlemail.com Thu Apr 10 09:53:57 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Thu, 10 Apr 2014 11:53:57 +0200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: References: Message-ID: <2791680.7JZClt2jd3@linux-hpeb.site> On Wednesday 09 April 2014, 23:42:26, Carter Schonwald wrote: > i bet you have cabal --version reply with 1.16 > > 1) cabal update > 2) cabal install cabal-install > 3) rm ~/.cabal/config # old pre 1.18 config should go! > 4) cabal update # also probably add ~/.cabal/bin to path There should be a step to edit the config file here, one may want to change a number of default settings, such as documentation library-profiling shared library-for-ghci split-objs > 5) cabal install vector From michael at snoyman.com Thu Apr 10 09:55:46 2014 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 10 Apr 2014 12:55:46 +0300 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: References: Message-ID: On Thu, Apr 10, 2014 at 6:42 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > i bet you have cabal --version reply with 1.16 :) > > 1) cabal update > 2) cabal install cabal-install > 3) rm ~/.cabal/config # old pre 1.18 config should go! > This was news to me. Is there a list of the important changes? > 4) cabal update # also probably add ~/.cabal/bin to path > 5) cabal install vector > > > > On Wed, Apr 9, 2014 at 11:24 PM, Vivian McPhail < > haskell.vivian.mcphail at gmail.com> wrote: > >> Hi, >> >> Ubuntu 12.04, 64 bit x86, ghc 7.8.1 gives the following: >> >> # cabal install --global vector >> ... >> [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( >> Data/Vector/Fusion/Stream/Monadic.hs, >> dist/build/Data/Vector/Fusion/Stream/Monadic.o ) >> Loading package ghc-prim ... linking ... done. >> Loading package integer-gmp ... linking ... done. >> Loading package base ... linking ... done. >> Loading package primitive-0.5.2.1 ... : can't load .so/.DLL >> for: libHSprimitive-0.5.2.1.so (libHSprimitive-0.5.2.1.so: cannot open >> shared object file: No such file or directory) >> cabal: Error: some packages failed to install: >> vector-0.10.9.1 failed during the building phase. The exception was: >> ExitFailure 1 >> >> Cheers, >> >> Vivian >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Apr 10 09:59:34 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 10 Apr 2014 11:59:34 +0200 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' In-Reply-To: (Conal Elliott's message of "Wed, 9 Apr 2014 10:53:47 -0700") References: Message-ID: <87txa133p5.fsf@gnu.org> On 2014-04-09 at 19:53:47 +0200, Conal Elliott wrote: > From a bit of experimentation, it appears that the problematic packages do > indeed have Haddock failures. For instance, > > bash-3.2$ cd random-1.0.1.1/ > bash-3.2$ cabal configure > Resolving dependencies... > Configuring random-1.0.1.1... > bash-3.2$ cabal haddock > Running Haddock for random-1.0.1.1... > Preprocessing library random-1.0.1.1... > Haddock coverage: > > System/Random.hs:2:2: parse error on input '#' Fyi, this one specifically looks as if it could be related to https://github.com/haskell/cabal/issues/1740#issuecomment-39559026 I.e. caused by `clang -E` not being "semi-idempotent" (meaning the result from the second CPP pass can't be parsed anymore by GHC) From hvr at gnu.org Thu Apr 10 10:03:32 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 10 Apr 2014 12:03:32 +0200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: (Vivian McPhail's message of "Thu, 10 Apr 2014 16:00:43 +1200") References: Message-ID: <87ppkp33ij.fsf@gnu.org> On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote: > Indeed. > > It was using the wrong cabal-install version. Even though I had installed > the newest cabal-install I needed to restart the xterm I was working > in. Lemme guess, you're using Bash, and you installed cabal-install into a new location; however Bash caches the paths of called executables, see also http://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables From haskell.vivian.mcphail at gmail.com Thu Apr 10 10:13:01 2014 From: haskell.vivian.mcphail at gmail.com (Vivian McPhail) Date: Thu, 10 Apr 2014 22:13:01 +1200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: <87ppkp33ij.fsf@gnu.org> References: <87ppkp33ij.fsf@gnu.org> Message-ID: Yes, exactly. On 10 April 2014 22:03, Herbert Valerio Riedel wrote: > On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote: > > Indeed. > > > > It was using the wrong cabal-install version. Even though I had > installed > > the newest cabal-install I needed to restart the xterm I was working > > in. > > Lemme guess, you're using Bash, and you installed cabal-install into a > new location; however Bash caches the paths of called executables, see also > > > http://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell.vivian.mcphail at gmail.com Thu Apr 10 10:15:50 2014 From: haskell.vivian.mcphail at gmail.com (Alexander McPhail) Date: Thu, 10 Apr 2014 22:15:50 +1200 Subject: 7.8.1 cabal install of vector package (dependent on primitive package) fails In-Reply-To: <87ppkp33ij.fsf@gnu.org> References: <87ppkp33ij.fsf@gnu.org> Message-ID: Yes, exactly. Thank you. On 10 April 2014 22:03, Herbert Valerio Riedel wrote: > On 2014-04-10 at 06:00:43 +0200, Vivian McPhail wrote: > > Indeed. > > > > It was using the wrong cabal-install version. Even though I had > installed > > the newest cabal-install I needed to restart the xterm I was working > > in. > > Lemme guess, you're using Bash, and you installed cabal-install into a > new location; however Bash caches the paths of called executables, see also > > > http://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables > -- --- yolar et elver. --- DISCLAIMER This transmission contains information that may be confidential. It is intended for the named addressee only. Unless you are the named addressee you may not copy or use it or disclose it to anyone else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Thu Apr 10 15:44:31 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Thu, 10 Apr 2014 18:44:31 +0300 Subject: -optl behavior in ghc-7.8.1 Message-ID: <1397144671.4722.10.camel@shum-lt> Hi, I found that -optl behavior was changed in ghc-7.8.1 ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite. $ /opt/ghc-7.6.3/bin/ghc --make main.hs -optl=hello -v ... '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'main' 'main.o' 'hello' ... ... $ /opt/ghc-7.8.1/bin/ghc --make main.hs -optl=hello -v ... /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE hello -o main main.o ... ... Is it intentional change? I want to compile in a number of static libraries. I have the next line in my cabal file: ld-options: ./path/to/libsomething.a It works ok on linux and mac os with ghc-7.6.3, but with ghc-7.8.1 I get undefined references for symbols from the libsomething.a Thanks, Yuras From allbery.b at gmail.com Thu Apr 10 15:54:45 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 11:54:45 -0400 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <1397144671.4722.10.camel@shum-lt> References: <1397144671.4722.10.camel@shum-lt> Message-ID: On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich wrote: > ghc-7.6.3 passes additional linker options after all the haskell object > files, while ghc-7.8.1 does the opposite. (...) > Is it intentional change? > Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be. I want to compile in a number of static libraries. I have the next line > in my cabal file: > > ld-options: ./path/to/libsomething.a > You're abusing ld-options. Use extra-libraries for this; if it doesn't work then you have found another bug and should file it as such. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Thu Apr 10 16:02:41 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Thu, 10 Apr 2014 19:02:41 +0300 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: References: <1397144671.4722.10.camel@shum-lt> Message-ID: <1397145761.4722.15.camel@shum-lt> On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: > On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich wrote: > > > ghc-7.6.3 passes additional linker options after all the haskell object > > files, while ghc-7.8.1 does the opposite. > > (...) > > > Is it intentional change? > > > > Pretty sure it is intentional, because it's necessary for some options. ld > options are not in general position independent, and can't be. Yes, I understand. But how the new behavior is better then the old one? > > I want to compile in a number of static libraries. I have the next line > > in my cabal file: > > > > ld-options: ./path/to/libsomething.a > > > > You're abusing ld-options. Use extra-libraries for this; if it doesn't work > then you have found another bug and should file it as such. extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a From allbery.b at gmail.com Thu Apr 10 16:13:45 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 12:13:45 -0400 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <1397145761.4722.15.camel@shum-lt> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> Message-ID: On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich wrote: > On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: > > On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich >wrote: > > > Is it intentional change? > > > > Pretty sure it is intentional, because it's necessary for some options. > ld > > options are not in general position independent, and can't be. > > Yes, I understand. But how the new behavior is better then the old one? If it was not clear from what I said that some linker options must come before objects/libraries to have any effect then I am not sure what will clarify it for you. > > ld-options: ./path/to/libsomething.a > > > > You're abusing ld-options. Use extra-libraries for this; if it doesn't > work > > then you have found another bug and should file it as such. > > extra-libraries doesn't work because it links with libsomething.so > instead of libsomething.a > Don't specify it using -l..., specify the .a file just as you were with ld-options. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Thu Apr 10 16:39:55 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Thu, 10 Apr 2014 19:39:55 +0300 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> Message-ID: <1397147995.4722.23.camel@shum-lt> On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote: > On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich wrote: > > > On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: > > > On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich > >wrote: > > > > Is it intentional change? > > > > > > Pretty sure it is intentional, because it's necessary for some options. > > ld > > > options are not in general position independent, and can't be. > > > > Yes, I understand. But how the new behavior is better then the old one? > > > If it was not clear from what I said that some linker options must come > before objects/libraries to have any effect then I am not sure what will > clarify it for you. ...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed. > > > > ld-options: ./path/to/libsomething.a > > > > > > You're abusing ld-options. Use extra-libraries for this; if it doesn't > > work > > > then you have found another bug and should file it as such. > > > > extra-libraries doesn't work because it links with libsomething.so > > instead of libsomething.a > > > > Don't specify it using -l..., specify the .a file just as you were with > ld-options. Are you kidding me? cabal unconditionally adds "-l" to extra-libraries. From karel.gardas at centrum.cz Thu Apr 10 16:49:27 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 10 Apr 2014 18:49:27 +0200 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <1397147995.4722.23.camel@shum-lt> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> Message-ID: <5346CB97.4030102@centrum.cz> On 04/10/14 06:39 PM, Yuras Shumovich wrote: > ...and other linker options must come after, like in my case. So what? > Are there any ticket where people complain about the old behavior? I'm > not advocating any specific behavior, I'm just asking why it was > changed. Hmm, I'm not sure if I'm the patch provider, but at least I provided patch which was merged into HEAD (don't have 7.8 branch here so check yourself) which fixes linking of binaries failure on Solaris. Please see b9b94ec82d9125da47c619c69e626120b3e60457 The core of the change is: - else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs the patch contains full explanation in comment so see it for more information. If this is not what bugs you, then please ignore me. Thanks, Karel From allbery.b at gmail.com Thu Apr 10 16:52:54 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 10 Apr 2014 12:52:54 -0400 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <1397147995.4722.23.camel@shum-lt> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> Message-ID: On Thu, Apr 10, 2014 at 12:39 PM, Yuras Shumovich wrote: > On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote: > > On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich >wrote: > > > On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: > > > > On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich < > shumovichy at gmail.com > > > >wrote: > > > > > Is it intentional change? > > > > > > > > Pretty sure it is intentional, because it's necessary for some > options. > > > ld > > > > options are not in general position independent, and can't be. > > > > > > Yes, I understand. But how the new behavior is better then the old one? > > > > If it was not clear from what I said that some linker options must come > > before objects/libraries to have any effect then I am not sure what will > > clarify it for you. > > ...and other linker options must come after, like in my case. So what? > Is your use case that much more important than everyone else's that other people's bugs must be rejected for your convenience? This has been an issue for other people and the change was needed. > Are you kidding me? cabal unconditionally adds "-l" to extra-libraries. > I may be misremembering some other option; I do recall people using direct references to static archives in cabal files, and not via ld-options where they don't belong. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Thu Apr 10 17:11:27 2014 From: shumovichy at gmail.com (Yuras Shumovich) Date: Thu, 10 Apr 2014 20:11:27 +0300 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <5346CB97.4030102@centrum.cz> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> <5346CB97.4030102@centrum.cz> Message-ID: <1397149887.4722.29.camel@shum-lt> On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote: > On 04/10/14 06:39 PM, Yuras Shumovich wrote: > > ...and other linker options must come after, like in my case. So what? > > Are there any ticket where people complain about the old behavior? I'm > > not advocating any specific behavior, I'm just asking why it was > > changed. > > Hmm, I'm not sure if I'm the patch provider, but at least I provided > patch which was merged into HEAD (don't have 7.8 branch here so check > yourself) which fixes linking of binaries failure on Solaris. Please see > b9b94ec82d9125da47c619c69e626120b3e60457 > > The core of the change is: > > - else package_hs_libs ++ extra_libs ++ other_flags > + else other_flags ++ package_hs_libs ++ extra_libs Thank you for pointing to the commit. I hoped it was incidental change, but now I see the reason. Thanks, Yuras > > the patch contains full explanation in comment so see it for more > information. > > If this is not what bugs you, then please ignore me. > > Thanks, > Karel From conal at conal.net Thu Apr 10 17:28:25 2014 From: conal at conal.net (Conal Elliott) Date: Thu, 10 Apr 2014 10:28:25 -0700 Subject: GHC 7.8.1: Many haddock-related complaints from 'ghc-pkg check' In-Reply-To: References: Message-ID: Thanks, Austin & Herbert. Switching from clang to gcc-4.8 and reinstalling libraries eliminated most of the noise for me. In one set of my own libraries (bringing in new dependencies), I did get several more haddock warnings from 'ghc-pkg check'. I reinstalled each of those libs explicitly (cabal install --reinstall --force-reinstalls), ignored the resulting warnings, and now back to a clean `ghc-pkg check`, and (so far) working packages. -- Conal On Wed, Apr 9, 2014 at 6:16 PM, Austin Seipp wrote: > Hi Conal, > > Damn, I think I somehow totally missed this. :( I'll look into on my > Mavericks machine and see what's going wrong - I figured ./validate > would have caught this, but perhaps something strange is going on. > > I filed a bug for you marked for 7.8.2: > https://ghc.haskell.org/trac/ghc/ticket/8981 > > On Wed, Apr 9, 2014 at 1:07 PM, Conal Elliott wrote: > > My concern about the volume of warnings here is that it distracts from > the > > info I'm after, namely broken packages. One coping strategy seems to be > > using the --simple-output flag to 'ghc-pkg check'. In that case, the > haddock > > warnings are suppressed, and I see just a list of broken package names. A > > little terser than I'm after, but it helps. > > > > > > On Wed, Apr 9, 2014 at 10:53 AM, Conal Elliott wrote: > >> > >> From a bit of experimentation, it appears that the problematic packages > do > >> indeed have Haddock failures. For instance, > >> > >> bash-3.2$ cd random-1.0.1.1/ > >> bash-3.2$ cabal configure > >> Resolving dependencies... > >> Configuring random-1.0.1.1... > >> bash-3.2$ cabal haddock > >> Running Haddock for random-1.0.1.1... > >> Preprocessing library random-1.0.1.1... > >> Haddock coverage: > >> > >> System/Random.hs:2:2: parse error on input '#' > >> > >> > >> > >> > >> On Wed, Apr 9, 2014 at 10:46 AM, Conal Elliott wrote: > >>> > >>> I installed the binary distribution of GHC 7.8.1 for Mac OS this > morning, > >>> cabal-installed a few packages, and now I get a *lot* of warnings about > >>> missing .haddock files: > >>> > >>> bash-3.2$ ghc-pkg check > >>> Warning: haddock-interfaces: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock > >>> doesn't exist or isn't a file > >>> Warning: haddock-interfaces: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock > >>> doesn't exist or isn't a file > >>> Warning: haddock-interfaces: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock > >>> doesn't exist or isn't a file > >>> Warning: haddock-interfaces: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock > >>> doesn't exist or isn't a file > >>> Warning: haddock-html: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html > >>> doesn't exist or isn't a directory > >>> Warning: haddock-interfaces: > >>> > /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock > >>> doesn't exist or isn't a file > >>> Warning: haddock-html: > >>> /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html > doesn't > >>> exist or isn't a directory > >>> ... > >>> > >>> Expected behavior? Avoidable? Fixable? > >>> > >>> Thanks, - Conal > >> > >> > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Apr 11 12:14:22 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 11 Apr 2014 14:14:22 +0200 Subject: can't load .so/.DLL - undefined symbol In-Reply-To: <532707CE.5090909@henning-thielemann.de> References: <531F8A0D.8060508@henning-thielemann.de> <5326BEB9.5010802@gmail.com> <532707CE.5090909@henning-thielemann.de> Message-ID: <5347DC9E.2060602@henning-thielemann.de> Am 17.03.2014 15:33, schrieb Henning Thielemann: > Am 17.03.2014 10:22, schrieb Simon Marlow: >> package. Perhaps you have a copy of that module on the search path >> somewhere, or inside the alsa-seq package? > > This would confirm how I understood the linker message. Then I guess > that compiling all packages at once in a single build dir with cabal was > the problem. The command line was like: > > $ cabal install --builddir=/tmp/dist --with-ghc=ghc7.8.0.20140228 poll > alsa-seq pkg1 pkg2 pkg3 ... > > After compiling the packages separately the problem has gone. I think I know what the problem was: 'poll' uses HSC as preprocessor, thus preprocessed files were stored in "dist". This way the preprocessed source files were available to GHC when compiling 'alsa' and thus it was compiled again, but not registered in the 'alsa' package. From austin at well-typed.com Sat Apr 12 13:30:56 2014 From: austin at well-typed.com (Austin Seipp) Date: Sat, 12 Apr 2014 08:30:56 -0500 Subject: ANNOUNCE: GHC version 7.8.2 Message-ID: ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.2. This is an important bugfix release relative to 7.8.1, so we highly recommend upgrading from 7.8.1. The full release notes are here: https://www.haskell.org/ghc/docs/7.8.2/html/users_guide/release-7-8-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: SHA256SUMS.sig Type: application/octet-stream Size: 836 bytes Desc: not available URL: From ramin.honary at gmail.com Sun Apr 13 15:08:48 2014 From: ramin.honary at gmail.com (Ramin Honary) Date: Mon, 14 Apr 2014 00:08:48 +0900 Subject: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64 Message-ID: I am posting this to the mailing list, but it is a copy of a post I originally made on Haskell Reddit. http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/ My GHC is working fine now. But there seem to be some changes in either GHC 7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in Hackage. *TL;DR* I discovered the "Crypto-4.2.5.1 package is broken, and trying to install "terminfo-0.4.0.0" breaks GHC by over-writing the terminfo library that came with the GHC tarball because isn't in the GHC package registry. I downloaded the binary distribution from here: https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.tar.bz2 and then immediately began re-building all of the packages in my .cabal/packages/hackage.haskell.org/ direcotry. I admit, all of my problems may be due to my Cabal config, but I haven't had any problems with it before this, as far as I know it is the default setup the option to build profiling libraries set to True. The first problem I had was that Crypto-2.5.4.1 was not building files correctly. *Some* of shared object files "*.dyn_o" were being built *without* their accompanying "*.dyn_hi" files, although some of the "*.dyn_hi" files did exist). When cabal tried to copy these "*.dyn_hi" files to the global package registry during installation it would fail with something about (for example) "could not find RSA.dyn_hi". To solve this, I rebuilt every "*.dyn_o" file that did not have an accompanying "*.dyn_hi" by hand using the command ghc -dynamic --make Codec.Binary.RSA The resulting "Codec/Binary/RSA.hi" file was actually a dynamic interface file but it's file extension was just ".hi" for some reason, (I double checked by using ghc --show-iface) so I just copied it it the "dist/build/Codec/Binary/" directory. I did this for every "*.hi" file that was supposed to be named "*.dyn_hi". This included about 10 files. Again, some "*.dyn_o" did build correctly with an accompanying "*.dyn_hi", about 10 of the modules were built incorrectly, all the rest were OK. The second problem I had was with installing "Yi" which relies on the "terminfo-0.4.0.0" package. The "terminfo" library that came with the GHC 7.8.2 binary distribution does not show up in the output of "ghc-pkg list", so Cabal tries to build it thinking it doesn't exist, and it overwrites the existing "terminfo-0.4.0.0" package with a library that contains missing symbols. This causes GHC to completely stop working. The "ghc" program immediately fails with an error: symbol lookup error: /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so: \ undefined symbol: terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info I was able to solve this problem by simply copying the contents of: ghc-7.8.2/libraries/terminfo/dist-install/build/* from the source distribution tarball to the GHC installation directory: /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/ and that solved the problem. But any program depending on "terminfo" simply will not install properly. The terminfo-0.4.0.0 package does not show up in the output of ghc-pkg list, even though it comes with the GHC 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will build a ".so" file that GHC cannot use. *So don't install terminfo-0.4.0.0 from Hackage.* Fortunately, Yi is not something that is absolutely necessary. I was able to install every other package I needed (lens, diagrams, yesod, xmonad, gtk) without incident. But whatever changes have been made in ghc-7.8.2 and the accompanying Cabal-1.18.1.3 seem to have broken some of the older Hackage packages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sun Apr 13 17:33:24 2014 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 13 Apr 2014 14:33:24 -0300 Subject: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64 In-Reply-To: References: Message-ID: I was able to do cabal install of terminfo, crypto and Yi on my mac with ghc 7.8.2 and cabal 1.18.1.3 yi seems to work although I did very little with it On Sun, Apr 13, 2014 at 12:08 PM, Ramin Honary wrote: > I am posting this to the mailing list, but it is a copy of a post I > originally made on Haskell Reddit. > > > http://www.reddit.com/r/haskell/comments/22wu92/problems_installing_ghc_782_on_debian_ubuntu_x86/ > > > My GHC is working fine now. But there seem to be some changes in either > GHC 7.8.2 or Cabal-1.18.1.3 that have broken some of the older packages in > Hackage. > > *TL;DR* I discovered the "Crypto-4.2.5.1 package is broken, and trying to > install "terminfo-0.4.0.0" breaks GHC by over-writing the terminfo library > that came with the GHC tarball because isn't in the GHC package registry. > > I downloaded the binary distribution from here: > > > https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown-linux-deb7.tar.bz2 > > and then immediately began re-building all of the packages in my > .cabal/packages/hackage.haskell.org/ direcotry. > > I admit, all of my problems may be due to my Cabal config, but I haven't > had any problems with it before this, as far as I know it is the default > setup the option to build profiling libraries set to True. > > The first problem I had was that Crypto-2.5.4.1 was not building files > correctly. *Some* of shared object files "*.dyn_o" were being built > *without* their accompanying "*.dyn_hi" files, although some of the > "*.dyn_hi" files did exist). When cabal tried to copy these "*.dyn_hi" > files to the global package registry during installation it would fail with > something about (for example) "could not find RSA.dyn_hi". To solve this, I > rebuilt every "*.dyn_o" file that did not have an accompanying "*.dyn_hi" > by hand using the command > > ghc -dynamic --make Codec.Binary.RSA > > The resulting "Codec/Binary/RSA.hi" file was actually a dynamic interface > file but it's file extension was just ".hi" for some reason, (I double > checked by using ghc --show-iface) so I just copied it it the > "dist/build/Codec/Binary/" directory. I did this for every "*.hi" file that > was supposed to be named "*.dyn_hi". This included about 10 files. Again, > some "*.dyn_o" did build correctly with an accompanying "*.dyn_hi", about > 10 of the modules were built incorrectly, all the rest were OK. > > The second problem I had was with installing "Yi" which relies on the > "terminfo-0.4.0.0" package. The "terminfo" library that came with the GHC > 7.8.2 binary distribution does not show up in the output of "ghc-pkg list", > so Cabal tries to build it thinking it doesn't exist, and it overwrites the > existing "terminfo-0.4.0.0" package with a library that contains missing > symbols. This causes GHC to completely stop working. The "ghc" program > immediately fails with an error: > > symbol lookup error: /usr/local/lib/ghc-7.8.2/bin/../haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.8.2.so: \ > undefined symbol: terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziCursor_moveDown5_info > > I was able to solve this problem by simply copying the contents of: > > ghc-7.8.2/libraries/terminfo/dist-install/build/* > > from the source distribution tarball to the GHC installation directory: > > /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0/ > > and that solved the problem. But any program depending on "terminfo" > simply will not install properly. The terminfo-0.4.0.0 package does not > show up in the output of ghc-pkg list, even though it comes with the GHC > 7.8.2 tarball and GHC relies on it. Attempting to install Terminfo will > build a ".so" file that GHC cannot use. *So don't install > terminfo-0.4.0.0 from Hackage.* > > Fortunately, Yi is not something that is absolutely necessary. I was able > to install every other package I needed (lens, diagrams, yesod, xmonad, > gtk) without incident. > > But whatever changes have been made in ghc-7.8.2 and the accompanying > Cabal-1.18.1.3 seem to have broken some of the older Hackage packages. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhp at community.haskell.org Mon Apr 14 04:42:20 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Mon, 14 Apr 2014 13:42:20 +0900 Subject: ANNOUNCE: GHC version 7.8.2 In-Reply-To: References: Message-ID: On 12 April 2014 22:30, Austin Seipp wrote: > > https://www.haskell.org/ghc/docs/7.8.2/html/users_guide/release-7-8-2.html Thank you very much! I have built it for Fedora 20 in my Copr repo: < https://copr.fedoraproject.org/coprs/petersen/ghc-7.8/>. (You can also install cabal-install-1.18 from < https://copr.fedoraproject.org/coprs/petersen/cabal-install/>) We plan to add ghc-7.8 officially to Fedora 21: < https://fedoraproject.org/wiki/Changes/GHC_7.8> (wip). Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 04:59:37 2014 From: conal at conal.net (Conal Elliott) Date: Sun, 13 Apr 2014 21:59:37 -0700 Subject: Help with coercion & roles? Message-ID: I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) "tpl"#) `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) ? LambdaCCC.Lambda.EP (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin _N (Sym (Simple.NTCo:HasIf[0] _N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 14 09:45:40 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 14 Apr 2014 09:45:40 +0000 Subject: Help with coercion & roles? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> I think you need a ?Sub?. A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 14 April 2014 06:00 To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org Subject: Help with coercion & roles? I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) "tpl"#) `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) ? LambdaCCC.Lambda.EP (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representational in _N (Sym (Simple.NTCo:HasIf[0] _N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Apr 14 11:39:01 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 07:39:01 -0400 Subject: Help with coercion & roles? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I agree with Simon, but just `Sub` the `_N`, not the whole coercion. There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. In sum, here is the coercion I think you want: (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. Let me know if I can help further! Richard On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > I think you need a ?Sub?. > > A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. > > Simon > > From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott > Sent: 14 April 2014 06:00 > To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > Subject: Help with coercion & roles? > > I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > LambdaCCC.Lambda.lamvP# > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > @ (Simple.HasIf GHC.Types.Bool) > "tpl"# > ((LambdaCCC.Lambda.varP# > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > "tpl"#) > `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) > ? LambdaCCC.Lambda.EP > (GHC.Types.Bool > ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > ~# > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. > > Thanks, > > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramin.honary at gmail.com Mon Apr 14 12:08:21 2014 From: ramin.honary at gmail.com (Ramin Honary) Date: Mon, 14 Apr 2014 21:08:21 +0900 Subject: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64 In-Reply-To: References: Message-ID: I am using Debian, not Mac. It is possible the problem may be with the binary release for Debian x86_64, or it could just be my Cabal config file. When I install the binary distribution onto Debian, I simply run "make install" in the ghc-7.8.2 directory. I don't know how this install process the creates the GHC package registry, but after a fresh install, the output of the "ghc-pkg list" command shows that "terminfo-0.4.0.0" is NOT installed even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory clearly exists and is populated with the correct library files. But since it is not registered Cabal tries to re-build it and overwrites the existing "terminfo-0.4.0.0" package. After a fresh install on Mac or Fedora, I wonder if "terminfo-0.4.0.0" shows up in the GHC package registry? It could be the package registry for the Debian binary distribution missed that detail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Mon Apr 14 13:07:29 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 14 Apr 2014 08:07:29 -0500 Subject: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64 In-Reply-To: References: Message-ID: Hi Ramin, Can I ask if you're installing packages into the global user database? If so, that's definitely the way for this to happen - otherwise, Cabal should never overwrite *anything* in the 'global' package directory (in your case, under /usr/local/lib/ghc-7.8.2...) This is the only way I can see this happening. In particular, installing 'terminfo' into my local package database ('cabal install terminfo') works fine... Carefully review your cabal configuration if you don't mind. You can also always force the installation using '--user' when running cabal. However, thank you very much for bringing this to my attention. What you have discovered is a real brainfart I don't think we had considered! The problem is that now that GHC is dynamically linked, we *cannot* get away with lying about whether those packages are installed - because they must install shared objects for GHC itself to work. That means overwriting them by accident (because we don't think they're installed) is a real possibility. Relatedly, the NixOS Haskell users are suffering from the same problem with 7.8.2 - http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012992.html - same problem, slightly different symptoms. See https://ghc.haskell.org/trac/ghc/ticket/8919 for the ticket. So this is definitely a real problem. I think scheduling the change for 7.8.3 is correct. My intuition tells me the fix might actually be quite simple - don't lie about xhtml and terminfo being installed, and just be honest. Is there any particular downside to doing this? I don't think so, *other* than the fact it does mean terminfo has to come along when it's not part of the Haskell Platform! On Mon, Apr 14, 2014 at 7:08 AM, Ramin Honary wrote: > I am using Debian, not Mac. It is possible the problem may be with the > binary release for Debian x86_64, or it could just be my Cabal config file. > > When I install the binary distribution onto Debian, I simply run "make > install" in the ghc-7.8.2 directory. I don't know how this install process > the creates the GHC package registry, but after a fresh install, the output > of the "ghc-pkg list" command shows that "terminfo-0.4.0.0" is NOT installed > even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory > clearly exists and is populated with the correct library files. But since it > is not registered Cabal tries to re-build it and overwrites the existing > "terminfo-0.4.0.0" package. > > After a fresh install on Mac or Fedora, I wonder if "terminfo-0.4.0.0" shows > up in the GHC package registry? It could be the package registry for the > Debian binary distribution missed that detail. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From marlowsd at gmail.com Mon Apr 14 14:42:49 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 14 Apr 2014 15:42:49 +0100 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <1397149887.4722.29.camel@shum-lt> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> <5346CB97.4030102@centrum.cz> <1397149887.4722.29.camel@shum-lt> Message-ID: <534BF3E9.1020200@gmail.com> On 10/04/2014 18:11, Yuras Shumovich wrote: > On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote: >> On 04/10/14 06:39 PM, Yuras Shumovich wrote: >>> ...and other linker options must come after, like in my case. So what? >>> Are there any ticket where people complain about the old behavior? I'm >>> not advocating any specific behavior, I'm just asking why it was >>> changed. >> >> Hmm, I'm not sure if I'm the patch provider, but at least I provided >> patch which was merged into HEAD (don't have 7.8 branch here so check >> yourself) which fixes linking of binaries failure on Solaris. Please see >> b9b94ec82d9125da47c619c69e626120b3e60457 >> >> The core of the change is: >> >> - else package_hs_libs ++ extra_libs ++ other_flags >> + else other_flags ++ package_hs_libs ++ extra_libs > > Thank you for pointing to the commit. I hoped it was incidental change, > but now I see the reason. Actually this was me: https://ghc.haskell.org/trac/ghc/changeset/1e2b3780ebc40d28cd0f029b90df102df09e6827/ghc The problem I was fixing was that we weren't always passing the -optl options. Now when we invoke a program the -optXXX options always come first - I think before it was kind of random and different for each of the phases. Cheers, Simon > > Thanks, > Yuras > >> >> the patch contains full explanation in comment so see it for more >> information. >> >> If this is not what bugs you, then please ignore me. >> >> Thanks, >> Karel > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > a From allbery.b at gmail.com Mon Apr 14 14:44:47 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 14 Apr 2014 10:44:47 -0400 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: <534BF3E9.1020200@gmail.com> References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> <5346CB97.4030102@centrum.cz> <1397149887.4722.29.camel@shum-lt> <534BF3E9.1020200@gmail.com> Message-ID: On Mon, Apr 14, 2014 at 10:42 AM, Simon Marlow wrote: > The problem I was fixing was that we weren't always passing the -optl > options. Now when we invoke a program the -optXXX options always come > first - I think before it was kind of random and different for each of the > phases. > Some things do need to come first, like that; but apparently we need either after-options or a more flexible library syntax. (Or an other-objects?) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramin.honary at gmail.com Mon Apr 14 17:35:20 2014 From: ramin.honary at gmail.com (Ramin Honary) Date: Tue, 15 Apr 2014 02:35:20 +0900 Subject: Fwd: Using Cabal to install terminfo-0.4.0.0 breaks GHC on Debian x86_64 In-Reply-To: References: Message-ID: Hi, thanks for your reply. Yes, I know for a fact I was installing to the global registry. All of my Haskell projects depend on a few important packages, and I always install these globally. For stuff I just want to play around with, I just install into the user registry. Actually terminfo-0.4.0.0 is not something any of my projects depend on, but I had installed it globally anyway and then this problem occurred. Also, the behavior Cabal installing Crypto-4.2.5.1 was odd. As I explained in my first e-mail, some of the shared modules were being built with file extensions of ".hi" instead of ".dyn_hi", but the "copy" phase of the Cabal installation was searching for files with ".dyn_hi" extensions and was failing. And not all modules were being built incorrectly, some modules had the correct ".dyn_hi", others had just ".hi". This may be a problem with the Crypto.cabal file, however. But anyway, the transition to using shared libraries by default has (in my experience) caused just these two hiccups. I'm glad I was able to expose this problem. -- Ramin Honary On Mon, Apr 14, 2014 at 10:07 PM, Austin Seipp wrote: > Hi Ramin, > > Can I ask if you're installing packages into the global user database? > If so, that's definitely the way for this to happen - otherwise, Cabal > should never overwrite *anything* in the 'global' package directory > (in your case, under /usr/local/lib/ghc-7.8.2...) This is the only way > I can see this happening. In particular, installing 'terminfo' into my > local package database ('cabal install terminfo') works fine... > > Carefully review your cabal configuration if you don't mind. You can > also always force the installation using '--user' when running cabal. > > However, thank you very much for bringing this to my attention. What > you have discovered is a real brainfart I don't think we had > considered! The problem is that now that GHC is dynamically linked, we > *cannot* get away with lying about whether those packages are > installed - because they must install shared objects for GHC itself to > work. That means overwriting them by accident (because we don't think > they're installed) is a real possibility. > > Relatedly, the NixOS Haskell users are suffering from the same problem > with 7.8.2 - > http://lists.science.uu.nl/pipermail/nix-dev/2014-April/012992.html > - same problem, slightly different symptoms. > > See https://ghc.haskell.org/trac/ghc/ticket/8919 for the ticket. > > So this is definitely a real problem. I think scheduling the change > for 7.8.3 is correct. > > My intuition tells me the fix might actually be quite simple - don't > lie about xhtml and terminfo being installed, and just be honest. Is > there any particular downside to doing this? I don't think so, *other* > than the fact it does mean terminfo has to come along when it's not > part of the Haskell Platform! > > > > On Mon, Apr 14, 2014 at 7:08 AM, Ramin Honary > wrote: > > I am using Debian, not Mac. It is possible the problem may be with the > > binary release for Debian x86_64, or it could just be my Cabal config > file. > > > > When I install the binary distribution onto Debian, I simply run "make > > install" in the ghc-7.8.2 directory. I don't know how this install > process > > the creates the GHC package registry, but after a fresh install, the > output > > of the "ghc-pkg list" command shows that "terminfo-0.4.0.0" is NOT > installed > > even though there the /usr/local/lib/ghc-7.8.2/terminfo-0.4.0.0 directory > > clearly exists and is populated with the correct library files. But > since it > > is not registered Cabal tries to re-build it and overwrites the existing > > "terminfo-0.4.0.0" package. > > > > After a fresh install on Mac or Fedora, I wonder if "terminfo-0.4.0.0" > shows > > up in the GHC package registry? It could be the package registry for the > > Debian binary distribution missed that detail. > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 18:23:45 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 11:23:45 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: > class HasIf a where > ifThenElse :: Bool -> a -> a -> a > > instance HasIf Bool where > ifThenElse i t e = (i && t) || (not i && e) With `--dump-tc`, I see > TYPE SIGNATURES > TYPE CONSTRUCTORS > HasIf :: * -> Constraint > class HasIf a > Roles: [nominal] > RecFlag NonRecursive > ifThenElse :: Bool -> a -> a -> a > COERCION AXIOMS > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > INSTANCES > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R -- Conal On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the > whole coercion. > > There are actually two problems here. The one Simon identified, and also > the fact that Simple.NTCo:HasIf[0] produces a representational coercion. > How do I know? Because of the `NT` -- it's a newtype axiom and must produce > representational coercions. Furthermore, unless the newtype definition is > inferred to require a nominal parameter, the newtype would expect a > representational coercion, not the nominal one you are passing. Check the > dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on > `` would work, you would then be violating an invariant of GHC's > Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl > (TyConApp tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within > GHC, and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles > and may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones > wrote: > > I think you need a ?Sub?. > > A cast (e `cast` g) requires a representational coercion. I think you > have given it a (stronger) nominal one. Sub gets from one to t?other. > > Simon > > *From:* Glasgow-haskell-users [mailto:glasgow- > haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 14 April 2014 06:00 > *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > *Subject:* Help with coercion & roles? > > > I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and > running into trouble with coercions & roles. Error message from Core Lint: > > Warning: In the expression: > > > > LambdaCCC.Lambda.lamvP# > > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > @ (Simple.HasIf GHC.Types.Bool) > > "tpl"# > > ((LambdaCCC.Lambda.varP# > > @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > "tpl"#) > > `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) > > ? LambdaCCC.Lambda.EP > > (GHC.Types.Bool > > ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) > > ~# > > LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) > > Role incompatibility: expected nominal, got representational > > in _N (Sym (Simple.NTCo:HasIf[0] _N)) > > Do you see anything inconsistent/incompatible in the coercions or roles > above? I constructed the nominal EP Refl coercion, and applied it (AppCo) > an existing coercion of a simpler type. > > Thanks, > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Apr 14 18:54:08 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 14:54:08 -0400 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Conal, In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the `HasIf` class indeed has a nominal parameter. So, it seems that this part, at least, is OK. What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what you're saying.) If that's the case, you won't be able to pass the result of NTCo:HasIf[0] to a coercion built from EP. Popping up a level, what are you trying to do here? If EP's role is indeed nominal, then I don't believe there's a fix here, as the coercion it seems you're trying to build may be unsound. (It looks to me like you want something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but if EP's role is nominal, then this is indeed bogus.) Richard On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > I agree with Simon, but just `Sub` the `_N`, not the whole coercion. > > There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. > > Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. > > In sum, here is the coercion I think you want: > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R > > This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. > > Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. > > Let me know if I can help further! > Richard > > On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: > >> I think you need a ?Sub?. >> >> A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. >> >> Simon >> >> From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott >> Sent: 14 April 2014 06:00 >> To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >> Subject: Help with coercion & roles? >> >> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: >> >> Warning: In the expression: >> >> >> LambdaCCC.Lambda.lamvP# >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> @ (Simple.HasIf GHC.Types.Bool) >> >> "tpl"# >> ((LambdaCCC.Lambda.varP# >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> "tpl"#) >> >> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> ? LambdaCCC.Lambda.EP >> (GHC.Types.Bool >> >> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> ~# >> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >> >> >> Role incompatibility: expected nominal, got representational >> >> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >> Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. >> >> Thanks, >> >> -- Conal >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 20:12:13 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 13:12:13 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Richard, I'm working on compiling Haskell to hardware, as outlined at https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a few recent blog posts). The first step is to convert Core into other Core that evaluates to a reified form, represented as a type-parametrized GADT. This GADT (in `LambdaCCC.Lambda`): > data E :: (* -> *) -> (* -> *) where ... The parameter is also type-parametrized, and is for the primitives. I have such a type designed for hardware generation (in `LambdaCCC.Prim`) > data Prim :: * -> * where ... and then the combination of the two: > type EP = E Prim So that's what `EP` is. With `-ddump-tc`, I get > TYPE CONSTRUCTORS > ... > E :: (* -> *) -> * -> * > data E ($a::* -> *) $b > No C type associated > Roles: [representational, nominal] > RecFlag NonRecursive, Not promotable > = ... > EP :: * -> * > type EP = E Prim The use of `EP` rather than the more general `E` is only temporary, while I'm learning more details of Core (and of HERMIT which I'm using to manipulate Core). I'm now working on reification in the presence of casts. The rule I'm trying to implement is > evalEP e |> co --> evalEP (e |> co'). Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. I'm trying to build `co'` from `co`, which led to these questions. So what do you think? Is there a sound coercion I can build for `co'`? -- Conal On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the > `HasIf` class indeed has a nominal parameter. So, it seems that this part, > at least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what > you're saying.) If that's the case, you won't be able to pass the result of > NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed > nominal, then I don't believe there's a fix here, as the coercion it seems > you're trying to build may be unsound. (It looks to me like you want > something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, > but if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > > Thanks for the pointers! I don't quite know how to get to the form you > recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] > _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from > the following code: > > > class HasIf a where > > ifThenElse :: Bool -> a -> a -> a > > > > instance HasIf Bool where > > ifThenElse i t e = (i && t) || (not i && e) > > With `--dump-tc`, I see > > > TYPE SIGNATURES > > TYPE CONSTRUCTORS > > HasIf :: * -> Constraint > > class HasIf a > > Roles: [nominal] > > RecFlag NonRecursive > > ifThenElse :: Bool -> a -> a -> a > > COERCION AXIOMS > > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a > > INSTANCES > > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 > > Do I need to convert the nominal coercion I got from GHC > (`Simple.NTCo:HasIf[0] _N` in this case) to a > representational one? If so, how? > My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to > apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which > then produces > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > And still I get "Role incompatibility: expected nominal, got > representational in `Sym (Simple.NTCo:HasIf[0] _N)`". > > I also tried wrapping `mkSubCo` around the entire coercion (applying > `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: > > > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R > > -- Conal > > > > On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: > >> I agree with Simon, but just `Sub` the `_N`, not the >> whole coercion. >> >> There are actually two problems here. The one Simon identified, and also >> the fact that Simple.NTCo:HasIf[0] produces a representational coercion. >> How do I know? Because of the `NT` -- it's a newtype axiom and must produce >> representational coercions. Furthermore, unless the newtype definition is >> inferred to require a nominal parameter, the newtype would expect a >> representational coercion, not the nominal one you are passing. Check the >> dump (using -ddump-tc) of the newtype axiom to be sure. >> >> Though putting a `Sub` on `` and changing the Refl constructor on >> `` would work, you would then be violating an invariant of GHC's >> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl >> (TyConApp tc [])) ...`. >> >> In sum, here is the coercion I think you want: >> >> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >> >> This is one of the problems with roles -- they are *very* fiddly within >> GHC, and it's hard for a non-expert in roles to get them right. >> >> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles >> and may be of help. >> >> Let me know if I can help further! >> Richard >> >> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones >> wrote: >> >> I think you need a ?Sub?. >> >> A cast (e `cast` g) requires a representational coercion. I think you >> have given it a (stronger) nominal one. Sub gets from one to t?other. >> >> Simon >> >> *From:* Glasgow-haskell-users [mailto:glasgow- >> haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott >> *Sent:* 14 April 2014 06:00 >> *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >> *Subject:* Help with coercion & roles? >> >> >> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and >> running into trouble with coercions & roles. Error message from Core Lint: >> >> Warning: In the expression: >> >> >> >> LambdaCCC.Lambda.lamvP# >> >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> @ (Simple.HasIf GHC.Types.Bool) >> >> "tpl"# >> >> ((LambdaCCC.Lambda.varP# >> >> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> "tpl"#) >> >> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> ? LambdaCCC.Lambda.EP >> >> (GHC.Types.Bool >> >> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >> >> ~# >> >> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >> >> Role incompatibility: expected nominal, got representational >> >> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >> >> Do you see anything inconsistent/incompatible in the coercions or roles >> above? I constructed the nominal EP Refl coercion, and applied it (AppCo) >> an existing coercion of a simpler type. >> >> Thanks, >> -- Conal >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Apr 14 21:02:33 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 14 Apr 2014 17:02:33 -0400 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > So what do you think? Is there a sound coercion I can build for `co'`? In a word, "no". The problem is that E, as you describe, is a GADT. Therefore, it cares exactly which types it is parameterized by. We can see this in evidence in the dump, which labels E's second parameter as nominal. To draw out the problem, let's look at a simpler example: > newtype Age = MkAge Int > data G a where > MkGInt :: G Int > MkGAge :: G Age Here, `G` would similarly get a nominal role, because we can't lift representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, which goes against our definition of G -- the only value inhabitant of G Int should be MkGInt. The best you can do here is to try to raise the inner coercion to be nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the ability of GHC's type system. Of course, I would like to help you with a way forward -- let me know if there's a way I can. Richard On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links to a few recent blog posts). The first step is to convert Core into other Core that evaluates to a reified form, represented as a type-parametrized GADT. This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while I'm learning more details of Core (and of HERMIT which I'm using to manipulate Core). > > I'm now working on reification in the presence of casts. The rule I'm trying to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > Hi Conal, > > In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the `HasIf` class indeed has a nominal parameter. So, it seems that this part, at least, is OK. > > What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what you're saying.) If that's the case, you won't be able to pass the result of NTCo:HasIf[0] to a coercion built from EP. > > Popping up a level, what are you trying to do here? If EP's role is indeed nominal, then I don't believe there's a fix here, as the coercion it seems you're trying to build may be unsound. (It looks to me like you want something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, but if EP's role is nominal, then this is indeed bogus.) > > Richard > > On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: > >> Thanks for the pointers! I don't quite know how to get to the form you recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC (`Simple.NTCo:HasIf[0] _N` in this case) to a representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which then produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected nominal, got representational in `Sym (Simple.NTCo:HasIf[0] _N)`". >> >> I also tried wrapping `mkSubCo` around the entire coercion (applying `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> -- Conal >> >> >> On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: >> I agree with Simon, but just `Sub` the `_N`, not the whole coercion. >> >> There are actually two problems here. The one Simon identified, and also the fact that Simple.NTCo:HasIf[0] produces a representational coercion. How do I know? Because of the `NT` -- it's a newtype axiom and must produce representational coercions. Furthermore, unless the newtype definition is inferred to require a nominal parameter, the newtype would expect a representational coercion, not the nominal one you are passing. Check the dump (using -ddump-tc) of the newtype axiom to be sure. >> >> Though putting a `Sub` on `` and changing the Refl constructor on `` would work, you would then be violating an invariant of GHC's Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl (TyConApp tc [])) ...`. >> >> In sum, here is the coercion I think you want: >> >> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >> >> This is one of the problems with roles -- they are *very* fiddly within GHC, and it's hard for a non-expert in roles to get them right. >> >> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles and may be of help. >> >> Let me know if I can help further! >> Richard >> >> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones wrote: >> >>> I think you need a ?Sub?. >>> >>> A cast (e `cast` g) requires a representational coercion. I think you have given it a (stronger) nominal one. Sub gets from one to t?other. >>> >>> Simon >>> >>> From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott >>> Sent: 14 April 2014 06:00 >>> To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >>> Subject: Help with coercion & roles? >>> >>> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: >>> >>> Warning: In the expression: >>> >>> >>> LambdaCCC.Lambda.lamvP# >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> @ (Simple.HasIf GHC.Types.Bool) >>> >>> "tpl"# >>> ((LambdaCCC.Lambda.varP# >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> "tpl"#) >>> >>> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> ? LambdaCCC.Lambda.EP >>> (GHC.Types.Bool >>> >>> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> ~# >>> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >>> >>> >>> Role incompatibility: expected nominal, got representational >>> >>> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >>> Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. >>> >>> Thanks, >>> >>> -- Conal >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 14 22:04:10 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 14 Apr 2014 15:04:10 -0700 Subject: Help with coercion & roles? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF156146@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This explanation-with-example is very helpful. Thanks, Richard! I'll noodle some more. A fairly simple & robust solution may be to add `Cast` to my expression GADT. -- Conal On Mon, Apr 14, 2014 at 2:02 PM, Richard Eisenberg wrote: > So what do you think? Is there a sound coercion I can build for `co'`? > > > In a word, "no". The problem is that E, as you describe, is a GADT. > Therefore, it cares exactly which types it is parameterized by. We can see > this in evidence in the dump, which labels E's second parameter as nominal. > To draw out the problem, let's look at a simpler example: > > > newtype Age = MkAge Int > > data G a where > > MkGInt :: G Int > > MkGAge :: G Age > > Here, `G` would similarly get a nominal role, because we can't lift > representational coercions (such as NTCo:Age :: Age ~R Int) through the `G` > type constructor. If we could, we could then have (MkGAge |> ...) :: G Int, > which goes against our definition of G -- the only value inhabitant of G > Int should be MkGInt. > > The best you can do here is to try to raise the inner coercion to be > nominal, by unSubCo_maybe. If that fails, I think you've gone beyond the > ability of GHC's type system. > > Of course, I would like to help you with a way forward -- let me know if > there's a way I can. > > Richard > > On Apr 14, 2014, at 4:12 PM, Conal Elliott wrote: > > Hi Richard, > > I'm working on compiling Haskell to hardware, as outlined at > https://github.com/conal/lambda-ccc/blob/master/doc/notes.md (with links > to a few recent blog posts). The first step is to convert Core into other > Core that evaluates to a reified form, represented as a type-parametrized > GADT. This GADT (in `LambdaCCC.Lambda`): > > > data E :: (* -> *) -> (* -> *) where ... > > The parameter is also type-parametrized, and is for the primitives. I have > such a type designed for hardware generation (in `LambdaCCC.Prim`) > > > data Prim :: * -> * where ... > > and then the combination of the two: > > > type EP = E Prim > > So that's what `EP` is. > > With `-ddump-tc`, I get > > > TYPE CONSTRUCTORS > > ... > > E :: (* -> *) -> * -> * > > data E ($a::* -> *) $b > > No C type associated > > Roles: [representational, nominal] > > RecFlag NonRecursive, Not promotable > > = ... > > EP :: * -> * > > type EP = E Prim > > The use of `EP` rather than the more general `E` is only temporary, while > I'm learning more details of Core (and of HERMIT which I'm using to > manipulate Core). > > I'm now working on reification in the presence of casts. The rule I'm > trying to implement is > > > evalEP e |> co --> evalEP (e |> co'). > > Here, `evalEP :: EP a -> a` and `co :: a ~ b`, so `co' :: EP a ~ EP b`. > > I'm trying to build `co'` from `co`, which led to these questions. > > So what do you think? Is there a sound coercion I can build for `co'`? > > -- Conal > > > On Mon, Apr 14, 2014 at 11:54 AM, Richard Eisenberg wrote: > >> Hi Conal, >> >> In your case, the `_N` on the argument to NTCo:HasIf[0] is correct -- the >> `HasIf` class indeed has a nominal parameter. So, it seems that this part, >> at least, is OK. >> >> What's the -ddump-tc on EP? Is EP's role nominal? (I think so, given what >> you're saying.) If that's the case, you won't be able to pass the result of >> NTCo:HasIf[0] to a coercion built from EP. >> >> Popping up a level, what are you trying to do here? If EP's role is >> indeed nominal, then I don't believe there's a fix here, as the coercion it >> seems you're trying to build may be unsound. (It looks to me like you want >> something proving `EP (Bool -> Bool -> Bool -> Bool) ~R EP (HasIf Bool)`, >> but if EP's role is nominal, then this is indeed bogus.) >> >> Richard >> >> On Apr 14, 2014, at 2:23 PM, Conal Elliott wrote: >> >> Thanks for the pointers! I don't quite know how to get to the form you >> recommend from the existing coercion, which is `Simple.NTCo:HasIf[0] >> _N`. (Note the `_N`.) I got that coercion in GHC 7.8.2 from >> the following code: >> >> > class HasIf a where >> > ifThenElse :: Bool -> a -> a -> a >> > >> > instance HasIf Bool where >> > ifThenElse i t e = (i && t) || (not i && e) >> >> With `--dump-tc`, I see >> >> > TYPE SIGNATURES >> > TYPE CONSTRUCTORS >> > HasIf :: * -> Constraint >> > class HasIf a >> > Roles: [nominal] >> > RecFlag NonRecursive >> > ifThenElse :: Bool -> a -> a -> a >> > COERCION AXIOMS >> > axiom Main.NTCo:HasIf :: HasIf a = Bool -> a -> a -> a >> > INSTANCES >> > instance HasIf Bool -- Defined at ../test/HasIf.hs:4:10 >> >> Do I need to convert the nominal coercion I got from GHC >> (`Simple.NTCo:HasIf[0] _N` in this case) to a >> representational one? If so, how? >> My current formulation (tweaked to use `mkSubCo` and `mkAppCo`) is to >> apply `mkAppCo (mkSubCo (Refl Nominal ep))` to the given coercion, which >> then produces >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> And still I get "Role incompatibility: expected nominal, got >> representational in `Sym (Simple.NTCo:HasIf[0] _N)`". >> >> I also tried wrapping `mkSubCo` around the entire coercion (applying >> `mkSubCo . mkAppCo (Refl Nominal ep)`), and I see the same result: >> >> > (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _N)))_R >> >> -- Conal >> >> >> >> On Mon, Apr 14, 2014 at 4:39 AM, Richard Eisenberg wrote: >> >>> I agree with Simon, but just `Sub` the `_N`, not >>> the whole coercion. >>> >>> There are actually two problems here. The one Simon identified, and also >>> the fact that Simple.NTCo:HasIf[0] produces a representational coercion. >>> How do I know? Because of the `NT` -- it's a newtype axiom and must produce >>> representational coercions. Furthermore, unless the newtype definition is >>> inferred to require a nominal parameter, the newtype would expect a >>> representational coercion, not the nominal one you are passing. Check the >>> dump (using -ddump-tc) of the newtype axiom to be sure. >>> >>> Though putting a `Sub` on `` and changing the Refl constructor on >>> `` would work, you would then be violating an invariant of GHC's >>> Coercion type: that we prefer `TyConAppCo tc ...` over `AppCo (Refl >>> (TyConApp tc [])) ...`. >>> >>> In sum, here is the coercion I think you want: >>> >>> (LambdaCCC.Lambda.EP (Sym (Simple.NTCo:HasIf[0] _R)))_R >>> >>> This is one of the problems with roles -- they are *very* fiddly within >>> GHC, and it's hard for a non-expert in roles to get them right. >>> >>> Have you seen docs/core-spec/core-spec.pdf? That is updated w.r.t. roles >>> and may be of help. >>> >>> Let me know if I can help further! >>> Richard >>> >>> On Apr 14, 2014, at 5:45 AM, Simon Peyton Jones >>> wrote: >>> >>> I think you need a ?Sub?. >>> >>> A cast (e `cast` g) requires a representational coercion. I think you >>> have given it a (stronger) nominal one. Sub gets from one to t?other. >>> >>> Simon >>> >>> *From:* Glasgow-haskell-users [mailto:glasgow- >>> haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott >>> *Sent:* 14 April 2014 06:00 >>> *To:* ghc-devs at haskell.org; glasgow-haskell-users at haskell.org >>> *Subject:* Help with coercion & roles? >>> >>> >>> I?m working on a GHC plugin (as part of my Haskell-to-hardware work) and >>> running into trouble with coercions & roles. Error message from Core Lint: >>> >>> Warning: In the expression: >>> >>> >>> >>> LambdaCCC.Lambda.lamvP# >>> >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> @ (Simple.HasIf GHC.Types.Bool) >>> >>> "tpl"# >>> >>> ((LambdaCCC.Lambda.varP# >>> >>> @ (GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> "tpl"#) >>> >>> `cast` (_N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> ? LambdaCCC.Lambda.EP >>> >>> (GHC.Types.Bool >>> >>> ? GHC.Types.Bool ? GHC.Types.Bool ? GHC.Types.Bool) >>> >>> ~# >>> >>> LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) >>> >>> Role incompatibility: expected nominal, got representational >>> >>> in _N (Sym (Simple.NTCo:HasIf[0] _N)) >>> >>> Do you see anything inconsistent/incompatible in the coercions or roles >>> above? I constructed the nominal EP Refl coercion, and applied it (AppCo) >>> an existing coercion of a simpler type. >>> >>> Thanks, >>> -- Conal >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Apr 15 19:51:12 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 15 Apr 2014 20:51:12 +0100 Subject: -optl behavior in ghc-7.8.1 In-Reply-To: References: <1397144671.4722.10.camel@shum-lt> <1397145761.4722.15.camel@shum-lt> <1397147995.4722.23.camel@shum-lt> <5346CB97.4030102@centrum.cz> <1397149887.4722.29.camel@shum-lt> <534BF3E9.1020200@gmail.com> Message-ID: <534D8DB0.1020805@gmail.com> On 14/04/2014 15:44, Brandon Allbery wrote: > On Mon, Apr 14, 2014 at 10:42 AM, Simon Marlow > wrote: > > The problem I was fixing was that we weren't always passing the > -optl options. Now when we invoke a program the -optXXX options > always come first - I think before it was kind of random and > different for each of the phases. > > > Some things do need to come first, like that; but apparently we need > either after-options or a more flexible library syntax. (Or an > other-objects?) If you need control over the ordering of all the linker options, you just put -optl in front of them all (object files, library files, -l, -L). Then you'll need at least one object file (an empty one will do) to convince GHC that you actually want to run the linker though. FWIW, this is what our build system does. Cheers, Simon From conal at conal.net Tue Apr 15 23:39:30 2014 From: conal at conal.net (Conal Elliott) Date: Tue, 15 Apr 2014 16:39:30 -0700 Subject: Concrete syntax for open type kind? Message-ID: I see ?#? for unlifted and ??? for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind :: { IfaceKind } : akind { $1 } | akind '->' kind { ifaceArrow $1 $3 } However, I don?t know how to get GHC to accept ?#? or ??? in a kind annotation. Are these kinds really available to source programs. I see that undefined has an open-kinded type: *Main> :i undefined undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? Looking in the GHC.Err source, I just see the following: undefined :: a undefined = error "Prelude.undefined" However, if I try similarly, q :: a q = error "q" I don?t see a similar type: *X> :i q q :: forall a. a -- Defined at ../test/X.hs:12:1 I don't know what kind 'a' has here, nor how to find out. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Wed Apr 16 00:09:06 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 15 Apr 2014 20:09:06 -0400 Subject: Concrete syntax for open type kind? In-Reply-To: References: Message-ID: What version of the GHC code are you looking at? The parser is currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t have these lines. As far as I know, there is no way to refer to OpenKind from source. You?re absolutely right about the type of `undefined`. `undefined` (and `error`) have magical types. GHC knows that GHC.Err defines an `undefined` symbol and gives it its type by fiat. There is no way (I believe) to reproduce this behavior. If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, quantified variables of kind * are not given kinds in the output. So, the lack of a kind annotation tells you that `a`?s kind is *. Any other kind (assuming these flags) would be printed. I hope this helps! Richard On Apr 15, 2014, at 7:39 PM, Conal Elliott wrote: > I see ?#? for unlifted and ??? for open kinds in compiler/parser/Parser.y: > akind :: { IfaceKind } > : '*' { ifaceLiftedTypeKind } > | '#' { ifaceUnliftedTypeKind } > | '?' { ifaceOpenTypeKind } > | '(' kind ')' { $2 } > > kind :: { IfaceKind } > : akind { $1 } > | akind '->' kind { ifaceArrow $1 $3 } > However, I don?t know how to get GHC to accept ?#? or ??? in a kind annotation. Are these kinds really available to source programs. > > I see that undefined has an open-kinded type: > > *Main> :i undefined > undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? > Looking in the GHC.Err source, I just see the following: > > undefined :: a > undefined = error "Prelude.undefined" > However, if I try similarly, > > q :: a > q = error "q" > I don?t see a similar type: > > *X> :i q > q :: forall a. a -- Defined at ../test/X.hs:12:1 > > I don't know what kind 'a' has here, nor how to find out. > > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Apr 16 15:19:30 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 16 Apr 2014 17:19:30 +0200 Subject: Autocomplete command line options with GHC 7.8 Message-ID: <201404161719.30203.jan.stolarek@p.lodz.pl> Hi all, GHC 7.8 adds --show-options flag that prints all supported command line flags on standard output. This can be used to enable autocompletion of command line options for ghc in shells that support autocompletion. If you're using bash add this snippet to your ~/.bashrc file: <<<<<<<<<<<<< START # Autocomplete GHC commands _ghc() { local envs=`ghc --show-options` # get the word currently being completed local cur=${COMP_WORDS[$COMP_CWORD]} # the resulting completions should be put into this array COMPREPLY=( $( compgen -W "$envs" -- $cur ) ) } complete -F _ghc -o default ghc <<<<<<<<<<<< END Enjoy. Janek PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags Feel free to add instructions for other shells. From philip.dexter at gmail.com Wed Apr 16 16:03:38 2014 From: philip.dexter at gmail.com (Philip Dexter) Date: Wed, 16 Apr 2014 12:03:38 -0400 (EDT) Subject: Autocomplete command line options with GHC 7.8 In-Reply-To: <201404161719.30203.jan.stolarek@p.lodz.pl> References: <201404161719.30203.jan.stolarek@p.lodz.pl> Message-ID: On Wed, 16 Apr 2014, Jan Stolarek wrote: > PS. I also added a wiki page: https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags > Feel free to add instructions for other shells. Zsh autocompletion resides on the haskell wiki [1]. There are also updated versions of both _cabal and _ghc (PR pending) at [2]. _ghc also includes completions for ghci and ghc-pkg. [1] http://www.haskell.org/haskellwiki/Zsh [2] https://github.com/zsh-users/zsh-completions ps - I tried to register on trac to add this info to your page but my registration was marked as spam (even after answering a math question) From jan.stolarek at p.lodz.pl Wed Apr 16 16:49:41 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 16 Apr 2014 18:49:41 +0200 Subject: Autocomplete command line options with GHC 7.8 In-Reply-To: References: <201404161719.30203.jan.stolarek@p.lodz.pl> Message-ID: <201404161849.41679.jan.stolarek@p.lodz.pl> Thanks Philip. > ps - I tried to register on trac to add this info to your page but my > registration was marked as spam (even after answering a math question) I believe you have to contact Herbert about that (CC'd). In the meantime I added this information to GHC wiki, although it would be nice to be able to use --show-options under zsh as well. From my understanding scripts that you linked to need to be manually updated, whereas --show-options displays all flags defined in the code of GHC. Janek From philip.dexter at gmail.com Wed Apr 16 16:54:48 2014 From: philip.dexter at gmail.com (Philip Dexter) Date: Wed, 16 Apr 2014 12:54:48 -0400 (EDT) Subject: Autocomplete command line options with GHC 7.8 In-Reply-To: <201404161849.41679.jan.stolarek@p.lodz.pl> References: <201404161719.30203.jan.stolarek@p.lodz.pl> <201404161849.41679.jan.stolarek@p.lodz.pl> Message-ID: On Wed, 16 Apr 2014, Jan Stolarek wrote: > In the meantime I added this information to GHC wiki, although it would be nice to be able to > use --show-options under zsh as well. From my understanding scripts that you linked to need to be > manually updated, whereas --show-options displays all flags defined in the code of GHC. Yes, that is true. There are tradeoffs. Zsh does provide a brief description of each auto-completed flag which you cannot achieve with --show-options. Perhaps it could be some sort of fallback where if an option and its description isn't provided, the plain result from --show-options could be used. Hmmm From conal at conal.net Wed Apr 16 17:01:11 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 16 Apr 2014 10:01:11 -0700 Subject: Concrete syntax for open type kind? In-Reply-To: References: Message-ID: Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. Too bad it's not possible to replicate this type interpretation of `error` and `undefined`. I'm doing some Core transformation, and I have a polymorphic function (reify) that I want to apply to expressions of lifted and unlifted types, as a way of structuring the transformation. When my transformation gets to unlifted types, the application violates the *-kindedness of my polymorphic function. I can probably find a way around. Maybe I'll build the kind-incorrect applications and then make sure to transform them away in the end. Currently, the implementation invokes `error`. Does anyone remember the justification of not having unlifted or open kinds in the source language? -- Conal On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg wrote: > What version of the GHC code are you looking at? The parser is currently > stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t have these > lines. As far as I know, there is no way to refer to OpenKind from source. > > You?re absolutely right about the type of `undefined`. `undefined` (and > `error`) have magical types. GHC knows that GHC.Err defines an `undefined` > symbol and gives it its type by fiat. There is no way (I believe) to > reproduce this behavior. > > If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, > quantified variables of kind * are not given kinds in the output. So, the > lack of a kind annotation tells you that `a`?s kind is *. Any other kind > (assuming these flags) would be printed. > > I hope this helps! > Richard > > On Apr 15, 2014, at 7:39 PM, Conal Elliott wrote: > > I see ?#? for unlifted and ??? for open kinds in compiler/parser/Parser.y: > > akind :: { IfaceKind } > : '*' { ifaceLiftedTypeKind } > | '#' { ifaceUnliftedTypeKind } > | '?' { ifaceOpenTypeKind } > | '(' kind ')' { $2 } > > kind :: { IfaceKind } > : akind { $1 } > | akind '->' kind { ifaceArrow $1 $3 } > > However, I don?t know how to get GHC to accept ?#? or ??? in a kind > annotation. Are these kinds really available to source programs. > > I see that undefined has an open-kinded type: > > *Main> :i undefined > undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? > > Looking in the GHC.Err source, I just see the following: > > undefined :: a > undefined = error "Prelude.undefined" > > However, if I try similarly, > > q :: a > q = error "q" > > I don?t see a similar type: > > *X> :i q > q :: forall a. a -- Defined at ../test/X.hs:12:1 > > > I don't know what kind 'a' has here, nor how to find out. > > -- Conal > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Apr 16 21:35:44 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 16 Apr 2014 21:35:44 +0000 Subject: Concrete syntax for open type kind? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF15F2F6@DB3PRD3001MB020.064d.mgd.msft.net> Does anyone remember the justification of not having unlifted or open kinds in the source language? They aren?t in the source language because they are a gross hack, with many messy consequences. Particularly the necessary sub-kinding, and the impact on inference. I?m not proud of it. But I do have a plan. Namely to use polymorphism. Currently we have kinds k ::= * | # | ? | k1 -> k2 | ... Instead I propose kinds k ::= TYPE bx | k1 -> k2 | .... boxity bx ::= BOXED | UNBOXED | bv where bv is a boxity variable So ? * = TYPE BOXED ? # = TYPE UNBOXED ? ? = TYPE bv Now error is polymorphic: error :: forall bv. forall (a:TYPE bv). String -> a And now everything will work out smoothly I think. And it should be reasonably easy to expose in the source language. All that said, there?s never enough time to do these things. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 16 April 2014 18:01 To: Richard Eisenberg Cc: glasgow-haskell-users at haskell.org Subject: Re: Concrete syntax for open type kind? Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. Too bad it's not possible to replicate this type interpretation of `error` and `undefined`. I'm doing some Core transformation, and I have a polymorphic function (reify) that I want to apply to expressions of lifted and unlifted types, as a way of structuring the transformation. When my transformation gets to unlifted types, the application violates the *-kindedness of my polymorphic function. I can probably find a way around. Maybe I'll build the kind-incorrect applications and then make sure to transform them away in the end. Currently, the implementation invokes `error`. Does anyone remember the justification of not having unlifted or open kinds in the source language? -- Conal On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg > wrote: What version of the GHC code are you looking at? The parser is currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t have these lines. As far as I know, there is no way to refer to OpenKind from source. You?re absolutely right about the type of `undefined`. `undefined` (and `error`) have magical types. GHC knows that GHC.Err defines an `undefined` symbol and gives it its type by fiat. There is no way (I believe) to reproduce this behavior. If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, quantified variables of kind * are not given kinds in the output. So, the lack of a kind annotation tells you that `a`?s kind is *. Any other kind (assuming these flags) would be printed. I hope this helps! Richard On Apr 15, 2014, at 7:39 PM, Conal Elliott > wrote: I see ?#? for unlifted and ??? for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind :: { IfaceKind } : akind { $1 } | akind '->' kind { ifaceArrow $1 $3 } However, I don?t know how to get GHC to accept ?#? or ??? in a kind annotation. Are these kinds really available to source programs. I see that undefined has an open-kinded type: *Main> :i undefined undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? Looking in the GHC.Err source, I just see the following: undefined :: a undefined = error "Prelude.undefined" However, if I try similarly, q :: a q = error "q" I don?t see a similar type: *X> :i q q :: forall a. a -- Defined at ../test/X.hs:12:1 I don't know what kind 'a' has here, nor how to find out. -- Conal _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Sat Apr 19 00:10:59 2014 From: conal at conal.net (Conal Elliott) Date: Fri, 18 Apr 2014 17:10:59 -0700 Subject: Concrete syntax for open type kind? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF15F2F6@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF15F2F6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks for that explanation, Simon. The new scheme sounds neater, indeed. Looks like the same trick used for inheritance mentioned in Calling *hell*from *heaven* and *heaven* from *hell* . Meanwhile, I think I can work around the limitation, somewhat clumsily, of no open kinds if I could make a definition polymorphic over unlifted kinds, e.g., > foo :: # > foo = error "foo?" Is it possible to do so with any sort of concrete syntax? -- Conal On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones wrote: > Does anyone remember the justification of not having unlifted or open > kinds in the source language? > > They aren?t in the source language because they are a gross hack, with > many messy consequences. Particularly the necessary sub-kinding, and the > impact on inference. I?m not proud of it. > > > > But I do have a plan. Namely to use polymorphism. Currently we have > > kinds k ::= * | # | ? | k1 -> k2 | ... > > > > Instead I propose > > kinds k ::= TYPE bx | k1 -> k2 | .... > > boxity bx ::= BOXED | UNBOXED | bv > > where bv is a boxity variable > > > > So > > ? * = TYPE BOXED > > ? # = TYPE UNBOXED > > ? ? = TYPE bv > > Now error is polymorphic: > > error :: forall bv. forall (a:TYPE bv). String -> a > > > > And now everything will work out smoothly I think. And it should be > reasonably easy to expose in the source language. > > > > All that said, there?s never enough time to do these things. > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 16 April 2014 18:01 > *To:* Richard Eisenberg > *Cc:* glasgow-haskell-users at haskell.org > *Subject:* Re: Concrete syntax for open type kind? > > > > Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. > > Too bad it's not possible to replicate this type interpretation of `error` > and `undefined`. I'm doing some Core transformation, and I have a > polymorphic function (reify) that I want to apply to expressions of lifted > and unlifted types, as a way of structuring the transformation. When my > transformation gets to unlifted types, the application violates the > *-kindedness of my polymorphic function. I can probably find a way around. > Maybe I'll build the kind-incorrect applications and then make sure to > transform them away in the end. Currently, the implementation invokes > `error`. > > Does anyone remember the justification of not having unlifted or open > kinds in the source language? > > -- Conal > > > > On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg > wrote: > > What version of the GHC code are you looking at? The parser is > currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t > have these lines. As far as I know, there is no way to refer to OpenKind > from source. > > > > You?re absolutely right about the type of `undefined`. `undefined` (and > `error`) have magical types. GHC knows that GHC.Err defines an `undefined` > symbol and gives it its type by fiat. There is no way (I believe) to > reproduce this behavior. > > > > If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, > quantified variables of kind * are not given kinds in the output. So, the > lack of a kind annotation tells you that `a`?s kind is *. Any other kind > (assuming these flags) would be printed. > > > > I hope this helps! > > Richard > > > > On Apr 15, 2014, at 7:39 PM, Conal Elliott wrote: > > > > I see ?#? for unlifted and ??? for open kinds in > compiler/parser/Parser.y: > > akind :: { IfaceKind } > > : '*' { ifaceLiftedTypeKind } > > | '#' { ifaceUnliftedTypeKind } > > | '?' { ifaceOpenTypeKind } > > | '(' kind ')' { $2 } > > > > kind :: { IfaceKind } > > : akind { $1 } > > | akind '->' kind { ifaceArrow $1 $3 } > > However, I don?t know how to get GHC to accept ?#? or ??? in a kind > annotation. Are these kinds really available to source programs. > > I see that undefined has an open-kinded type: > > *Main> :i undefined > > undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? > > Looking in the GHC.Err source, I just see the following: > > undefined :: a > > undefined = error "Prelude.undefined" > > However, if I try similarly, > > q :: a > > q = error "q" > > I don?t see a similar type: > > *X> :i q > > q :: forall a. a -- Defined at ../test/X.hs:12:1 > > > > I don't know what kind 'a' has here, nor how to find out. > > -- Conal > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sat Apr 19 17:18:31 2014 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sat, 19 Apr 2014 12:18:31 -0500 Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy' Message-ID: I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: $ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... ghc: /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol `memcpy' ghc: unable to load package `ghc-prim' $ memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc and -opt-lc options to ghci, in vain. From roma at ro-che.info Sat Apr 19 17:50:11 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 19 Apr 2014 20:50:11 +0300 Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy' In-Reply-To: References: Message-ID: <20140419175011.GA19381@sniper> * M Farkas-Dyck [2014-04-19 12:18:31-0500] > I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: > > $ ghci > GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... ghc: > /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol > `memcpy' > ghc: unable to load package `ghc-prim' > $ > > memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc > and -opt-lc options to ghci, in vain. Don't know if it helps, but I think ghci loads the dynamic library, not the static one. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From strake888 at gmail.com Sat Apr 19 17:51:55 2014 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sat, 19 Apr 2014 12:51:55 -0500 Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy' In-Reply-To: References: Message-ID: Further information: musl 1.0.0 Ghc as a compiler works, but ghci and runghc fail. From strake888 at gmail.com Sat Apr 19 17:59:40 2014 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sat, 19 Apr 2014 12:59:40 -0500 Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy' In-Reply-To: <20140419175011.GA19381@sniper> References: <20140419175011.GA19381@sniper> Message-ID: On 19/04/2014, Roman Cheplyaka wrote: > Don't know if it helps, but I think ghci loads the dynamic library, not the static one. I straced both the broken ghci on aforesaid system and a working ghci on a glibc system and it loads bare .o files. From roma at ro-che.info Sat Apr 19 17:59:39 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 19 Apr 2014 20:59:39 +0300 Subject: HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy' In-Reply-To: References: <20140419175011.GA19381@sniper> Message-ID: <20140419175939.GA19721@sniper> * M Farkas-Dyck [2014-04-19 12:55:23-0500] > On 19/04/2014, Roman Cheplyaka wrote: > > Don't know if it helps, but I think ghci loads the dynamic library, not the static one. > > I straced both the broken ghci on aforesaid system and a working ghci > on a glibc system and it loads bare .o files. Interesting. I thought that has changed in 7.8. I'd love to see an explanation from someone knowledgeable. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From simonpj at microsoft.com Mon Apr 21 07:20:52 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 07:20:52 +0000 Subject: Concrete syntax for open type kind? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF15F2F6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A554B65@DB3PRD3001MB020.064d.mgd.msft.net> Is it possible to do so with any sort of concrete syntax? I?m afraid not. And I?m strongly disinclined to add it because we?d then just delete it again. Are you really really stuck? S From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 19 April 2014 01:11 To: Simon Peyton Jones Cc: glasgow-haskell-users at haskell.org Subject: Re: Concrete syntax for open type kind? Thanks for that explanation, Simon. The new scheme sounds neater, indeed. Looks like the same trick used for inheritance mentioned in Calling hell from heaven and heaven from hell. Meanwhile, I think I can work around the limitation, somewhat clumsily, of no open kinds if I could make a definition polymorphic over unlifted kinds, e.g., > foo :: # > foo = error "foo?" Is it possible to do so with any sort of concrete syntax? -- Conal On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones > wrote: Does anyone remember the justification of not having unlifted or open kinds in the source language? They aren?t in the source language because they are a gross hack, with many messy consequences. Particularly the necessary sub-kinding, and the impact on inference. I?m not proud of it. But I do have a plan. Namely to use polymorphism. Currently we have kinds k ::= * | # | ? | k1 -> k2 | ... Instead I propose kinds k ::= TYPE bx | k1 -> k2 | .... boxity bx ::= BOXED | UNBOXED | bv where bv is a boxity variable So ? * = TYPE BOXED ? # = TYPE UNBOXED ? ? = TYPE bv Now error is polymorphic: error :: forall bv. forall (a:TYPE bv). String -> a And now everything will work out smoothly I think. And it should be reasonably easy to expose in the source language. All that said, there?s never enough time to do these things. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 16 April 2014 18:01 To: Richard Eisenberg Cc: glasgow-haskell-users at haskell.org Subject: Re: Concrete syntax for open type kind? Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. Too bad it's not possible to replicate this type interpretation of `error` and `undefined`. I'm doing some Core transformation, and I have a polymorphic function (reify) that I want to apply to expressions of lifted and unlifted types, as a way of structuring the transformation. When my transformation gets to unlifted types, the application violates the *-kindedness of my polymorphic function. I can probably find a way around. Maybe I'll build the kind-incorrect applications and then make sure to transform them away in the end. Currently, the implementation invokes `error`. Does anyone remember the justification of not having unlifted or open kinds in the source language? -- Conal On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg > wrote: What version of the GHC code are you looking at? The parser is currently stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t have these lines. As far as I know, there is no way to refer to OpenKind from source. You?re absolutely right about the type of `undefined`. `undefined` (and `error`) have magical types. GHC knows that GHC.Err defines an `undefined` symbol and gives it its type by fiat. There is no way (I believe) to reproduce this behavior. If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, quantified variables of kind * are not given kinds in the output. So, the lack of a kind annotation tells you that `a`?s kind is *. Any other kind (assuming these flags) would be printed. I hope this helps! Richard On Apr 15, 2014, at 7:39 PM, Conal Elliott > wrote: I see ?#? for unlifted and ??? for open kinds in compiler/parser/Parser.y: akind :: { IfaceKind } : '*' { ifaceLiftedTypeKind } | '#' { ifaceUnliftedTypeKind } | '?' { ifaceOpenTypeKind } | '(' kind ')' { $2 } kind :: { IfaceKind } : akind { $1 } | akind '->' kind { ifaceArrow $1 $3 } However, I don?t know how to get GHC to accept ?#? or ??? in a kind annotation. Are these kinds really available to source programs. I see that undefined has an open-kinded type: *Main> :i undefined undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? Looking in the GHC.Err source, I just see the following: undefined :: a undefined = error "Prelude.undefined" However, if I try similarly, q :: a q = error "q" I don?t see a similar type: *X> :i q q :: forall a. a -- Defined at ../test/X.hs:12:1 I don't know what kind 'a' has here, nor how to find out. -- Conal _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 21 08:30:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 21 Apr 2014 08:30:59 +0000 Subject: Tightening up on inferred type signatures Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> Friends GHC generally obeys this rule * If GHC infers a type f::type, then it's OK for you to add a type signature saying exactly that. For example, it rejects inferred types that are ambiguous. I think this is a good property; it was certainly the source of many bug reports before inferred ambiguous types were rejected. However, up to now (including in 7.8) GHC hasn't followed this rule consistently. In particular, it will infer types like fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b (where PF is a type family). If you write this as a type signature, GHC will insist on FlexibleContexts and TypeFamilies. So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC check inferred types in the same way that it checks declared types, thus rejecting the above inferred type unless you give the language extensions. This makes the compiler more consistent. But it does mean that some code may be rejected that 7.8 accepts. This email is just a heads-up that you might want to compile your library with 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other breaking changes of course; e.g Applicative will finally be a superclass of Monad, for example. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Apr 21 12:25:10 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 21 Apr 2014 08:25:10 -0400 Subject: [core libraries] Tightening up on inferred type signatures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: No objections here. The types involved really *do* have FlexibleContexts in them, so it makes sense to require the extension. The upgrade path for library authors is also clear. It'll complain to add the extension, and they'll fix it by adding the line of code suggested and perhaps realize something about their code in the process. -Edward On Mon, Apr 21, 2014 at 4:30 AM, Simon Peyton Jones wrote: > Friends > > GHC generally obeys this rule > > ? If GHC infers a type *f::type*, then it?s OK for you to add a > type signature saying exactly that. > > For example, it rejects inferred types that are ambiguous. I think this > is a good property; it was certainly the source of many bug reports before > inferred ambiguous types were rejected. > > However, up to now (including in 7.8) GHC hasn?t followed this rule > consistently. In particular, it will infer types like > > fold :: (Functor (PF a), Regular a) => (PF a b -> b) -> a -> b > > (where PF is a type family). If you write this as a type signature, GHC > will insist on FlexibleContexts and TypeFamilies. > > So in https://ghc.haskell.org/trac/ghc/ticket/8883, Jan has made GHC > check inferred types in the same way that it checks declared types, thus > rejecting the above inferred type unless you give the language extensions. > > This makes the compiler more consistent. > > But it does mean that some code may be rejected that 7.8 accepts. This > email is just a heads-up that you might want to compile your library with > 7.10 (i.e. a snapshot of HEAD) well in advance. There will be other > breaking changes of course; e.g Applicative will finally be a superclass of > Monad, for example. > > Simon > > > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Apr 21 17:53:05 2014 From: conal at conal.net (Conal Elliott) Date: Mon, 21 Apr 2014 10:53:05 -0700 Subject: Concrete syntax for open type kind? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A554B65@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF15F2F6@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF0A554B65@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks, Simon. I wouldn?t say that I?m really really stuck yet, and I?d rather no one wasted time on a dead-end workaround. I like the plan you described using kind polymorphism instead of subkinding, because I think the relaxed kinds would naturally be inferred where I need them. The problem I?m trying to solve here is defining a GADT for statically typed expressions, where some types are lifted and some are unlifted: data E ? ? ? * where ? App ? ? (a ? ?) (b ? ?) . E (a ? b) ? E a ? E b ? All literals would be monomorphic and unlifted, and E itself is lifted, so we?d never need to represent anything of an open-kinded type in GHC?s RTS. Instead, the ? kinds here are purely for managing the type constraints needed to ensure well-typedness of represented expressions while still allowing enough generality, including both lifted and unlifted types. Without support for open kinds (somehow), I don?t know of any way to say what I need to say. I?ll keep trying to find ways to avoid this limitation. Meanwhile, I?d like to explore what it?d take to change over the current subkinding system to the polymorphic one. I?ve not done such a project, but I?d be glad to help and learn my way around in the process. -- Conal On Mon, Apr 21, 2014 at 12:20 AM, Simon Peyton Jones wrote: > Is it possible to do so with any sort of concrete syntax? > > I?m afraid not. And I?m strongly disinclined to add it because we?d then > just delete it again. Are you really really stuck? > > S > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 19 April 2014 01:11 > *To:* Simon Peyton Jones > > *Cc:* glasgow-haskell-users at haskell.org > *Subject:* Re: Concrete syntax for open type kind? > > > > Thanks for that explanation, Simon. The new scheme sounds neater, indeed. > Looks like the same trick used for inheritance mentioned in Calling *hell*from > *heaven* and *heaven* from *hell* > . > > Meanwhile, I think I can work around the limitation, somewhat clumsily, of > no open kinds if I could make a definition polymorphic over unlifted kinds, > e.g., > > > foo :: # > > > foo = error "foo?" > > Is it possible to do so with any sort of concrete syntax? > > -- Conal > > > > > > On Wed, Apr 16, 2014 at 2:35 PM, Simon Peyton Jones > wrote: > > Does anyone remember the justification of not having unlifted or open > kinds in the source language? > > They aren?t in the source language because they are a gross hack, with > many messy consequences. Particularly the necessary sub-kinding, and the > impact on inference. I?m not proud of it. > > > > But I do have a plan. Namely to use polymorphism. Currently we have > > kinds k ::= * | # | ? | k1 -> k2 | ... > > > > Instead I propose > > kinds k ::= TYPE bx | k1 -> k2 | .... > > boxity bx ::= BOXED | UNBOXED | bv > > where bv is a boxity variable > > > > So > > ? * = TYPE BOXED > > ? # = TYPE UNBOXED > > ? ? = TYPE bv > > Now error is polymorphic: > > error :: forall bv. forall (a:TYPE bv). String -> a > > > > And now everything will work out smoothly I think. And it should be > reasonably easy to expose in the source language. > > > > All that said, there?s never enough time to do these things. > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 16 April 2014 18:01 > *To:* Richard Eisenberg > *Cc:* glasgow-haskell-users at haskell.org > *Subject:* Re: Concrete syntax for open type kind? > > > > Oops! I was reading ParserCore.y, instead of Parser.y.pp. Thanks. > > Too bad it's not possible to replicate this type interpretation of `error` > and `undefined`. I'm doing some Core transformation, and I have a > polymorphic function (reify) that I want to apply to expressions of lifted > and unlifted types, as a way of structuring the transformation. When my > transformation gets to unlifted types, the application violates the > *-kindedness of my polymorphic function. I can probably find a way around. > Maybe I'll build the kind-incorrect applications and then make sure to > transform them away in the end. Currently, the implementation invokes > `error`. > > Does anyone remember the justification of not having unlifted or open > kinds in the source language? > > -- Conal > > > > On Tue, Apr 15, 2014 at 5:09 PM, Richard Eisenberg > wrote: > > What version of the GHC code are you looking at? The parser is currently > stored in compiler/parser/Parser.y.pp (note the pp) and doesn?t have these > lines. As far as I know, there is no way to refer to OpenKind from source. > > > > You?re absolutely right about the type of `undefined`. `undefined` (and > `error`) have magical types. GHC knows that GHC.Err defines an `undefined` > symbol and gives it its type by fiat. There is no way (I believe) to > reproduce this behavior. > > > > If you have -fprint-explicit-foralls and -fprint-explicit-kinds enabled, > quantified variables of kind * are not given kinds in the output. So, the > lack of a kind annotation tells you that `a`?s kind is *. Any other kind > (assuming these flags) would be printed. > > > > I hope this helps! > > Richard > > > > On Apr 15, 2014, at 7:39 PM, Conal Elliott wrote: > > > > I see ?#? for unlifted and ??? for open kinds in > compiler/parser/Parser.y: > > akind :: { IfaceKind } > > : '*' { ifaceLiftedTypeKind } > > | '#' { ifaceUnliftedTypeKind } > > | '?' { ifaceOpenTypeKind } > > | '(' kind ')' { $2 } > > > > kind :: { IfaceKind } > > : akind { $1 } > > | akind '->' kind { ifaceArrow $1 $3 } > > However, I don?t know how to get GHC to accept ?#? or ??? in a kind > annotation. Are these kinds really available to source programs. > > I see that undefined has an open-kinded type: > > *Main> :i undefined > > undefined :: forall (a :: OpenKind). a -- Defined in ?GHC.Err? > > Looking in the GHC.Err source, I just see the following: > > undefined :: a > > undefined = error "Prelude.undefined" > > However, if I try similarly, > > q :: a > > q = error "q" > > I don?t see a similar type: > > *X> :i q > > q :: forall a. a -- Defined at ../test/X.hs:12:1 > > > > I don't know what kind 'a' has here, nor how to find out. > > -- Conal > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Mon Apr 21 20:57:00 2014 From: vogt.adam at gmail.com (adam vogt) Date: Mon, 21 Apr 2014 16:57:00 -0400 Subject: Tightening up on inferred type signatures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: ] GHC generally obeys this rule ] ] ? If GHC infers a type f::type, then it?s OK for you to add a type ] signature saying exactly that. That rule suggests that -XScopedTypeVariables should be on by default, and that you shouldn't need a forall to bring the type variables into scope. I imagine that would lead to harder-to-fix breakage than #8883, but on the other hand type signatures in let/where are pretty rare. Regards, Adam From simonpj at microsoft.com Tue Apr 22 06:44:26 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 22 Apr 2014 06:44:26 +0000 Subject: [core libraries] Re: Tightening up on inferred type signatures In-Reply-To: <87ha5m45fm.fsf@ta.scs.stanford.edu> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> <87ha5m45fm.fsf@ta.scs.stanford.edu> Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) Simon | -----Original Message----- | From: haskell-core-libraries at googlegroups.com [mailto:haskell-core- | libraries at googlegroups.com] On Behalf Of David Mazieres | Sent: 22 April 2014 00:41 | To: Simon Peyton Jones; Haskell Libraries (libraries at haskell.org); | core-libraries-committee at haskell.org; GHC users | Subject: [core libraries] Re: Tightening up on inferred type signatures | | Simon Peyton Jones writes: | | > GHC generally obeys this rule | > | > * If GHC infers a type f::type, then it's OK for you to add a type | > signature saying exactly that. | | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? | | David | | -- | 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 at googlegroups.com. | For more options, visit https://groups.google.com/d/optout. From mechvel at botik.ru Tue Apr 22 18:53:36 2014 From: mechvel at botik.ru (Sergei Meshveliani) Date: Tue, 22 Apr 2014 22:53:36 +0400 Subject: installing random-1.0.1.1 Message-ID: <1398192816.27357.23.camel@one.mechvel.pereslavl.ru> People, can you, please, explain me how to make the `random' package visible for GHC ? I have * installed haskell-platform-2013.2.0.0, * `made' ghc-7.8.2 from source by ghc-7.6.3, and run make configure under ghc-7.8.2 for my DoCon program. docon.cabal has ---------------------------------------- ... tested-with: GHC build-type: Simple build-depends: base >= 4 && < 5, containers >= 0.3 && <= 0.5.5.1, random >= 1.0 && < 1.2 . exposed-modules: ... extensions: TypeSynonymInstances UndecidableInstances FlexibleContexts FlexibleInstances MultiParamTypeClasses OverlappingInstances RecordWildCards NamedFieldPuns DoAndIfThenElse ... ----------------------------------------- make configure reports runghc Setup.hs configure --ghc --prefix=/home/mechvel/docon/2.12/docon/source/inst -v Configuring docon-2.12... Setup.hs: At least the following dependencies are missing: random >=1.0 && <1.2 I do cabal install random, and now ghc-pkg list shows ------------------------------------- /home/mechvel/ghc/7.8.2/inst0/lib/ghc-7.8.2/package.conf.d Cabal-1.18.1.3 ... containers-0.5.5.1 ... ghc-7.8.2 ... unix-2.7.0.1 /home/mechvel/.ghc/x86_64-linux-7.8.2/package.conf.d random-1.0.1.1 -------------------------------------- But make configure still does not find random. The Haskell Platform is installed in the system area, ghc-7.8.2 and random-1.0.1.1 are installed in my home. Maybe, I need to run `register random' with some appropriate arguments? Can you, please, advise? Thanks, ------ Sergei From daniel.is.fischer at googlemail.com Tue Apr 22 19:27:19 2014 From: daniel.is.fischer at googlemail.com (Daniel Fischer) Date: Tue, 22 Apr 2014 21:27:19 +0200 Subject: installing random-1.0.1.1 In-Reply-To: <1398192816.27357.23.camel@one.mechvel.pereslavl.ru> References: <1398192816.27357.23.camel@one.mechvel.pereslavl.ru> Message-ID: <4127674.2ERKQfFBRM@linux-hpeb.site> On Tuesday 22 April 2014, 22:53:36, Sergei Meshveliani wrote: > People, > > can you, please, explain me how to make the `random' package visible for > GHC ? It is visible to GHC, but `cabal install random` installed the package into the user database: > and now ghc-pkg list > shows > > ------------------------------------- > /home/mechvel/ghc/7.8.2/inst0/lib/ghc-7.8.2/package.conf.d > ... > > /home/mechvel/.ghc/x86_64-linux-7.8.2/package.conf.d > random-1.0.1.1 > -------------------------------------- whereas > > make configure > > reports > > runghc Setup.hs configure --ghc by default only looks into the global package database. If you don't want to use the cabal tool to install your DoCon and stick with the `runghc Setup.hs ...` way, you have the choice to either - pass the --user flag to `runghc Setup.hs configure` so that it uses also the user package database where your random package sits (then DoCon is also installed for the user and not globally), or - install random in the global package database, `cabal install --global random` so that `runghc Setup.hs ...` finds the package in the global DB. Cheers, Daniel From Christian.Maeder at dfki.de Wed Apr 23 08:23:27 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed, 23 Apr 2014 10:23:27 +0200 Subject: ghc -M Message-ID: <5357787F.4070002@dfki.de> Hi, using "ghc -M" with ghc-7.8.2 under linux. I got a message: You must specify at least one -dep-suffix (and a failure). http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation.html#makefile-dependencies I've stopped using "ghc -M" now, but I think it should be documented better. Maybe dynamic linking complicated matters. Cheers Christian From mechvel at botik.ru Wed Apr 23 08:59:25 2014 From: mechvel at botik.ru (Sergei Meshveliani) Date: Wed, 23 Apr 2014 12:59:25 +0400 Subject: testing 7.8.2 Message-ID: <1398243565.8597.18.camel@one.mechvel.pereslavl.ru> Dear GHC developers, I have tested ghc-7.8.2-src by making it by ghc-7.6.3 under Debian Linux. Then I have `made' my DoCon-2.12 application by ghc-7.8.2. It looks all right. For any occasion, here are some test results. Comparing it to ghc-7.4.1 shows the following. 1) The default context reduction stack (21) is not sufficient, so, I add -fcontext-stack=30 to the options. 2) The resulting libHSdocon-2.12.a is 1/10 larger (but the DoCon source is not the same, and it is, may be 1/100 larger). 3) The Main executable test size is almost the same. 4) The test running speed is the same. 5) The minimal -M memory setting for running the test is 4300 Kb against 2400 Kb of ghc-6.4.1. Regards, ------ Sergei From ekmett at gmail.com Wed Apr 23 18:27:09 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 23 Apr 2014 14:27:09 -0400 Subject: [core libraries] Re: Tightening up on inferred type signatures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> <87ha5m45fm.fsf@ta.scs.stanford.edu> <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: You can wind up in perfectly legitimate situations where the name for the type you are working with isn't in scope, but where you can write a combinator that would infer to have that type. I'd hate to lose that. It is admittedly of marginal utility at first glance, but there are some tricks that actually need it, and it can also arise if a type synonym expands to a type that isn't exported or brought into scope, so trying to push this line of reasoning too far I is possibly not too productive. Parts of lens, constraints and probably a few other packages I maintain would break as hard data points. -Edward On Tue, Apr 22, 2014 at 2:44 AM, Simon Peyton Jones wrote: > | Independent of language extensions, what about types and classes whose > | names are not in scope. Is there an implicit "... if you import all > | the relevant symbols" and the end of the rule? > > Good point. I'm honestly unsure how far to push this one! (It'd be > relatively easy to check whether they were in scope and complain if not, > but ...) > > Simon > > | -----Original Message----- > | From: haskell-core-libraries at googlegroups.com [mailto:haskell-core- > | libraries at googlegroups.com] On Behalf Of David Mazieres > | Sent: 22 April 2014 00:41 > | To: Simon Peyton Jones; Haskell Libraries (libraries at haskell.org); > | core-libraries-committee at haskell.org; GHC users > | Subject: [core libraries] Re: Tightening up on inferred type signatures > | > | Simon Peyton Jones writes: > | > | > GHC generally obeys this rule > | > > | > * If GHC infers a type f::type, then it's OK for you to add a type > | > signature saying exactly that. > | > | Independent of language extensions, what about types and classes whose > | names are not in scope. Is there an implicit "... if you import all > | the relevant symbols" and the end of the rule? > | > | David > | > | -- > | 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 at googlegroups.com. > | For more options, visit https://groups.google.com/d/optout. > > -- > 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 at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu Apr 24 00:29:06 2014 From: conal at conal.net (Conal Elliott) Date: Wed, 23 Apr 2014 17:29:06 -0700 Subject: Help with cast error Message-ID: I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 24 07:58:00 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 24 Apr 2014 07:58:00 +0000 Subject: Help with cast error In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> (a ~ b) is a boxed, nominal equality. (a ~R# b) is an unboxed, representational equality So it is rightly rejected. For the boxed/unboxed thing, the paper ?practical aspects?? gives more detail. http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ I think you already know about the nominal/representational distinction. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Conal Elliott Sent: 24 April 2014 01:29 To: glasgow-haskell-users at haskell.org; ghc-devs at haskell.org; Richard Eisenberg; Simon Peyton Jones Subject: Help with cast error I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Thu Apr 24 16:13:14 2014 From: conal at conal.net (Conal Elliott) Date: Thu, 24 Apr 2014 09:13:14 -0700 Subject: Help with cast error In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A56192A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks for the summary and paper pointer! I'll study up. -- Conal On Thu, Apr 24, 2014 at 12:58 AM, Simon Peyton Jones wrote: > (a ~ b) is a *boxed*, *nominal* equality. > > (a ~R# b) is an *unboxed, representational* equality > > > > So it is rightly rejected. > > > For the boxed/unboxed thing, the paper ?practical aspects?? gives more > detail. > http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ > > > > I think you already know about the nominal/representational distinction. > > > > Simon > > > > *From:* Glasgow-haskell-users [mailto: > glasgow-haskell-users-bounces at haskell.org] *On Behalf Of *Conal Elliott > *Sent:* 24 April 2014 01:29 > *To:* glasgow-haskell-users at haskell.org; ghc-devs at haskell.org; Richard > Eisenberg; Simon Peyton Jones > *Subject:* Help with cast error > > > > I'd appreciate help with a cast-related Core Lint error I'm getting with a > GHC plugin I'm working on: > > Argument value doesn't match argument type: > Fun type: > Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => > EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) > Arg type: > ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) > Arg: > CO Sub (TFCo:R:EncVec[0] <'Z>_N _N) > ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] _N))_R > > (I omitted the module prefixes for brevity.) Do I have a role wrong here, > or maybe something more fundamental? > > I can easily supply more info if it'd help. > > Thanks, -- Conal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenchenxu at gmail.com Thu Apr 24 21:37:25 2014 From: shenchenxu at gmail.com (Shen Chen Xu) Date: Thu, 24 Apr 2014 17:37:25 -0400 Subject: Fwd: Type/type class information in GHC plugin In-Reply-To: <53598376.8050304@gmail.com> References: <53598376.8050304@gmail.com> Message-ID: <53598415.4050700@gmail.com> Hello everyone, I would like to write a GHC plugin which adds wrapper to functions. Say I have a function addWrapper :: Ord a => (a -> b) -> a -> b which is supposed to transform (assuming the argument is in the Ord class) foo = \ x -> ... into foo = addWrapper (\ x -> ...) This works fine if I'm only interested in wrapping functions of type Int -> Int, in which case I make addWrapper to also have type addWrapper :: (Int -> Int) -> Int -> Int and use mkCoreApp to apply addWrapper to the right hand side. However, if I want it to be polymorphic as described above, the transformed GHC Core for an Int -> Int function should look like foo = addHook @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fOrdInt (\ x -> ...) My question is, given the right hand side of foo, how do I construct the type/type class information inside Core shown above? Cheers, Shen From jwlato at gmail.com Fri Apr 25 01:15:43 2014 From: jwlato at gmail.com (John Lato) Date: Thu, 24 Apr 2014 18:15:43 -0700 Subject: how to compile non-dynamic ghc-7.8.2 ? Message-ID: Hello, I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit linux). I downloaded the source tarball, added DYNAMIC_GHC_PROGRAMS = NO to mk/build.mk, and did ./configure && ./make. ghc builds and everything seems to work (cabal installed a bunch of packages, ghci seems to work), however whenever I try to run Setup.hs dynamically (either 'runghc Setup.hs configure' or loading it with ghci and executing 'main') it dumps core. Compiling Setup.hs works, and nothing else has caused ghci to crash either (this email is a literate haskell file equivalent to Setup.hs). Building with DYNAMIC_GHC_PROGRAMS = YES works properly. With that in mind, I have a few questions: How should I compile a non-dynamic ghc? Is this a bug in ghc? Thanks, John L. * Setup.hs > import Distribution.Simple > main = defaultMain -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertram.felgenhauer at googlemail.com Fri Apr 25 12:36:24 2014 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri, 25 Apr 2014 14:36:24 +0200 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: References: Message-ID: <20140425123624.GA7497@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> John Lato wrote: > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit > linux). I downloaded the source tarball, added > > DYNAMIC_GHC_PROGRAMS = NO I've had success with setting both DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO and removing the 'dyn' way altogether from GhcLibWays by setting GhcLibWays = v explicitely. I expect that the latter is optional; my goal was only to speed up the build. (The lines were copied from the perf-cross settings.) Cheers, Bertram From marlowsd at gmail.com Fri Apr 25 13:17:25 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 25 Apr 2014 14:17:25 +0100 Subject: RFC: changes to -i flag for finding source files Message-ID: <535A6065.1000606@gmail.com> I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. src/ Graphics/ UI/ Gtk/ Button.hs Label.hs ... where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: ghc -iGraphics.UI.Gtk=src the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with "module Graphics.UI.Gtk.Button ...". The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. Pros: - simple implementation (but Cabal needs mods, see below) - solves the deep directory problem Cons: - It makes the rules about finding files a bit more complicated. People need to find source files too, not just compilers. - packages that want to be compatible with older compilers can't use it yet. - you can't use '=' in a source directory name (but we could pick a different syntax if necessary) - It won't work for Cabal packages until Cabal is modified to support it (PreProcess and SrcDist and perhaps Haddock are the only places affected, I think) - Hackage will need to reject packages that use this feature without also specifying ghc >= 7.10 and some cabal-version too. - Are there other tools/libraries that will need changes? Leksah? Cheers, Simon From daniel.trstenjak at gmail.com Fri Apr 25 14:08:31 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 25 Apr 2014 16:08:31 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <20140425140831.GA2816@machine> Hi Simon, I don't quite know what I should think about this addition. Currently you can be sure that modules correspond to directories. After this change you can't be sure anymore. I don't navigate source trees that much by 'cd'-ing into single directories, so deep hierarchies don't bother me that much. There're certainly good intentions in the naming schemes of Haskell modules, but sometimes they just feel a bit forced. So for the module name 'Graphics.UI.Gtk' I might just have chosen the name 'Gtk'. If the library itself wants to separate code into several modules, then the module names can get quite bulky. So using module names to origanize the code and to classifiy its meaning might be a bit too much. Well, just some thoughts. Greetings, Daniel From gridaphobe at gmail.com Fri Apr 25 14:16:03 2014 From: gridaphobe at gmail.com (Eric Seidel) Date: Fri, 25 Apr 2014 07:16:03 -0700 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: An alternative (and I think this has also been proposed before) is to simply drop the Graphics.UI header from the module hierarchy. The main con here is that there's an increased risk of module name-clashes, but GHC already solves this with the PackageImports extension. On Friday, April 25, 2014, Simon Marlow wrote: > I want to propose a simple change to the -i flag for finding source files. > The problem we often have is that when you're writing code for a library > that lives deep in the module hierarchy, you end up needing a deep > directory structure, e.g. > > src/ > Graphics/ > UI/ > Gtk/ > Button.hs > Label.hs > ... > > where the top few layers are all empty. There have been proposals of > elaborate solutions for this in the past (module grafting etc.), but I want > to propose something really simple that would avoid this problem with > minimal additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc will look > for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than > src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it > still begins with "module Graphics.UI.Gtk.Button ...". > > The implementation is only a few lines in the Finder (and probably rather > more in the manual and testsuite), but I wanted to get a sense of whether > people thought this would be a good idea, or if there's a better > alternative before I push it. > > Pros: > > - simple implementation (but Cabal needs mods, see below) > - solves the deep directory problem > > Cons: > > - It makes the rules about finding files a bit more complicated. > People need to find source files too, not just compilers. > - packages that want to be compatible with older compilers can't > use it yet. > - you can't use '=' in a source directory name (but we could pick > a different syntax if necessary) > - It won't work for Cabal packages until Cabal is modified to > support it (PreProcess and SrcDist and perhaps Haddock are the only > places affected, I think) > - Hackage will need to reject packages that use this feature without > also specifying ghc >= 7.10 and some cabal-version too. > - Are there other tools/libraries that will need changes? Leksah? > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Apr 25 14:34:44 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 25 Apr 2014 10:34:44 -0400 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> Message-ID: On Fri, Apr 25, 2014 at 10:16 AM, Eric Seidel wrote: > The main con here is that there's an increased risk of > module name-clashes, but GHC already solves this with the PackageImports > extension. IMO almost any use of PackageImports indicates a severe design flaw somewhere. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Fri Apr 25 14:46:30 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 25 Apr 2014 16:46:30 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> Message-ID: <20140425144630.GA7761@machine> On Fri, Apr 25, 2014 at 07:16:03AM -0700, Eric Seidel wrote: > An alternative (and I think this has also been proposed before) is to simply > drop the Graphics.UI header from the module hierarchy. The main con here is > that there's an increased risk of module?name-clashes, but GHC already solves > this with the PackageImports extension.? I think several of the issues might be resolved by just using the package name as the first module name. Greetings, Daniel From alain.odea at gmail.com Fri Apr 25 14:57:28 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 25 Apr 2014 14:57:28 +0000 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <458D5DAF-3CA6-480E-8BC6-A13EB6000014@gmail.com> I have trouble with this as it breaks expectations around directory structure mirroring the module hierarchy. I would be very confused reading the source code of a project that availed of this feature as it would break my expectations of how to navigate to source files based on their module hierarchy. I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah etc., but changing this may break the tool's ability to provide jump to symbol. I imagine other unforeseen challenges with source dependency analysis elsewhere in the GHC toolchain may also arise if they assume that the directory layout reflects the module hierarchy. The Java toolchain certainly falls over when the corresponding package-flattening trick is performed on a Java codebase. The workarounds are viral and wind up complicating builds considerably. I could also be totally out to lunch here. > On Apr 25, 2014, at 13:17, Simon Marlow wrote: > > I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. > > src/ > Graphics/ > UI/ > Gtk/ > Button.hs > Label.hs > ... > > where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with "module Graphics.UI.Gtk.Button ...". > > The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. > > Pros: > > - simple implementation (but Cabal needs mods, see below) > - solves the deep directory problem > > Cons: > > - It makes the rules about finding files a bit more complicated. > People need to find source files too, not just compilers. > - packages that want to be compatible with older compilers can't > use it yet. > - you can't use '=' in a source directory name (but we could pick > a different syntax if necessary) > - It won't work for Cabal packages until Cabal is modified to > support it (PreProcess and SrcDist and perhaps Haddock are the only > places affected, I think) > - Hackage will need to reject packages that use this feature without > also specifying ghc >= 7.10 and some cabal-version too. > - Are there other tools/libraries that will need changes? Leksah? > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From m at tweag.io Fri Apr 25 15:01:21 2014 From: m at tweag.io (Mathieu Boespflug) Date: Fri, 25 Apr 2014 17:01:21 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <20140425144630.GA7761@machine> References: <535A6065.1000606@gmail.com> <20140425144630.GA7761@machine> Message-ID: On Fri, Apr 25, 2014 at 4:46 PM, Daniel Trstenjak wrote: > On Fri, Apr 25, 2014 at 07:16:03AM -0700, Eric Seidel wrote: >> An alternative (and I think this has also been proposed before) is to simply >> drop the Graphics.UI header from the module hierarchy. The main con here is >> that there's an increased risk of module name-clashes, but GHC already solves >> this with the PackageImports extension. > > I think several of the issues might be resolved by just using the package name > as the first module name. Such a policy violates the separation of provenance from function principle, which I think is a good one. That is, I ought to be able to swap in a different implementation of a map for the standard one in the containers package without having to touch my code (especially if the exported API's happen to match). -- Mathieu Boespflug Founder at http://tweag.io. From daniel.trstenjak at gmail.com Fri Apr 25 15:14:51 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 25 Apr 2014 17:14:51 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> <20140425144630.GA7761@machine> Message-ID: <20140425151451.GB8860@machine> On Fri, Apr 25, 2014 at 05:01:21PM +0200, Mathieu Boespflug wrote: > That is, I ought to be able to swap in a different implementation of a > map for the standard one in the containers package without having to > touch my code (especially if the exported API's happen to match). That's certainly a nice property, but how often have you really used it? I just don't think that the current naming schemes will scale nicely. If more people will use Haskell, then there's a need for separating namespaces. Greetings, Daniel From ekmett at gmail.com Fri Apr 25 15:22:46 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 25 Apr 2014 11:22:46 -0400 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. -Edward > On Apr 25, 2014, at 9:17 AM, Simon Marlow wrote: > > I want to propose a simple change to the -i flag for finding source files. The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, e.g. > > src/ > Graphics/ > UI/ > Gtk/ > Button.hs > Label.h > ... > > where the top few layers are all empty. There have been proposals of elaborate solutions for this in the past (module grafting etc.), but I want to propose something really simple that would avoid this problem with minimal additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc will look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still begins with "module Graphics.UI.Gtk.Button ...". > > The implementation is only a few lines in the Finder (and probably rather more in the manual and testsuite), but I wanted to get a sense of whether people thought this would be a good idea, or if there's a better alternative before I push it. > > Pros: > > - simple implementation (but Cabal needs mods, see below) > - solves the deep directory problem > > Cons: > > - It makes the rules about finding files a bit more complicated. > People need to find source files too, not just compilers. > - packages that want to be compatible with older compilers can't > use it yet. > - you can't use '=' in a source directory name (but we could pick > a different syntax if necessary) > - It won't work for Cabal packages until Cabal is modified to > support it (PreProcess and SrcDist and perhaps Haddock are the only > places affected, I think) > - Hackage will need to reject packages that use this feature without > also specifying ghc >= 7.10 and some cabal-version too. > - Are there other tools/libraries that will need changes? Leksah? > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From felipe.lessa at gmail.com Fri Apr 25 15:59:49 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri, 25 Apr 2014 12:59:49 -0300 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> <20140425144630.GA7761@machine> Message-ID: <535A8675.2070209@gmail.com> Em 25-04-2014 12:01, Mathieu Boespflug escreveu: > Such a policy violates the separation of provenance from function > principle, which I think is a good one. That is, I ought to be able to > swap in a different implementation of a map for the standard one in > the containers package without having to touch my code (especially if > the exported API's happen to match). The work being done on Backpack seems like a much better solution than creating packages that export modules with the same names. http://plv.mpi-sws.org/backpack/ Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From felipe.lessa at gmail.com Fri Apr 25 16:01:43 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri, 25 Apr 2014 13:01:43 -0300 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> Message-ID: <535A86E7.6010001@gmail.com> Em 25-04-2014 12:22, Edward Kmett escreveu: > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. > > In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. > > That would enable this to get much greater penetration more quickly. What if you had a "real-src" directory with all your files as they are now, and a "src" symlink pointing inside your directory tree? Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: From jwlato at gmail.com Fri Apr 25 16:25:55 2014 From: jwlato at gmail.com (John Lato) Date: Fri, 25 Apr 2014 09:25:55 -0700 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: <20140425123624.GA7497@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20140425123624.GA7497@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: On Apr 25, 2014 5:36 AM, "Bertram Felgenhauer" < bertram.felgenhauer at googlemail.com> wrote: > > John Lato wrote: > > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit > > linux). I downloaded the source tarball, added > > > > DYNAMIC_GHC_PROGRAMS = NO > > I've had success with setting both > > DYNAMIC_BY_DEFAULT = NO > DYNAMIC_GHC_PROGRAMS = NO > > and removing the 'dyn' way altogether from GhcLibWays by setting > GhcLibWays = v explicitely. I expect that the latter is optional; > my goal was only to speed up the build. > > (The lines were copied from the perf-cross settings.) I tried disabling dynamicByDefault also, but that didn't help. It may be a problem with lib ways though, I'll try that. Thanks, John > Cheers, > > Bertram > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Apr 25 16:47:22 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 25 Apr 2014 12:47:22 -0400 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: References: <20140425123624.GA7497@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: @john, what version of cabal-install were you using? (i realize you're probably using the right one, but worth asking :) ) On Fri, Apr 25, 2014 at 12:25 PM, John Lato wrote: > > On Apr 25, 2014 5:36 AM, "Bertram Felgenhauer" < > bertram.felgenhauer at googlemail.com> wrote: > > > > John Lato wrote: > > > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on > 64-bit > > > linux). I downloaded the source tarball, added > > > > > > DYNAMIC_GHC_PROGRAMS = NO > > > > I've had success with setting both > > > > DYNAMIC_BY_DEFAULT = NO > > DYNAMIC_GHC_PROGRAMS = NO > > > > and removing the 'dyn' way altogether from GhcLibWays by setting > > GhcLibWays = v explicitely. I expect that the latter is optional; > > my goal was only to speed up the build. > > > > (The lines were copied from the perf-cross settings.) > > I tried disabling dynamicByDefault also, but that didn't help. It may be a > problem with lib ways though, I'll try that. > > Thanks, John > > > Cheers, > > > > Bertram > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Apr 25 16:51:29 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 25 Apr 2014 19:51:29 +0300 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A86E7.6010001@gmail.com> References: <535A6065.1000606@gmail.com> <535A86E7.6010001@gmail.com> Message-ID: <20140425165129.GA29470@sniper> * Felipe Lessa [2014-04-25 13:01:43-0300] > Em 25-04-2014 12:22, Edward Kmett escreveu: > > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. > > > > In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. > > > > That would enable this to get much greater penetration more quickly. > > What if you had a "real-src" directory with all your files as they are > now, and a "src" symlink pointing inside your directory tree? I don't think Windows users can enjoy this, but it's a neat idea. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ekmett at gmail.com Fri Apr 25 16:52:41 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 25 Apr 2014 12:52:41 -0400 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A86E7.6010001@gmail.com> References: <535A6065.1000606@gmail.com> <535A86E7.6010001@gmail.com> Message-ID: I check out and work on projects on a bunch of machines, so it is important that I can just pull with git and go. AFAIK, git doesn't understand them won't build symlinks for me, so it'd just become another setup step for very marginal benefit, and another thing to .gitignore. -Edward > On Apr 25, 2014, at 12:01 PM, Felipe Lessa wrote: > > Em 25-04-2014 12:22, Edward Kmett escreveu: >> +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. >> >> In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. >> >> That would enable this to get much greater penetration more quickly. > > What if you had a "real-src" directory with all your files as they are > now, and a "src" symlink pointing inside your directory tree? > > Cheers, > > -- > Felipe. > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ekmett at gmail.com Fri Apr 25 16:54:47 2014 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 25 Apr 2014 12:54:47 -0400 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <20140425165129.GA29470@sniper> References: <535A6065.1000606@gmail.com> <535A86E7.6010001@gmail.com> <20140425165129.GA29470@sniper> Message-ID: <58C708B1-BBF7-4DAF-8B43-D09172B30DCD@gmail.com> You can actually make symbolic links (as well as hard links and "directory junctions") on windows. -Edward > On Apr 25, 2014, at 12:51 PM, Roman Cheplyaka wrote: > > * Felipe Lessa [2014-04-25 13:01:43-0300] >> Em 25-04-2014 12:22, Edward Kmett escreveu: >>> +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. >>> >>> In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. >>> >>> That would enable this to get much greater penetration more quickly. >> >> What if you had a "real-src" directory with all your files as they are >> now, and a "src" symlink pointing inside your directory tree? > > I don't think Windows users can enjoy this, but it's a neat idea. > > Roman > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From roma at ro-che.info Fri Apr 25 16:57:12 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 25 Apr 2014 19:57:12 +0300 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> Message-ID: <20140425165712.GB29470@sniper> * Edward Kmett [2014-04-25 11:22:46-0400] > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous > subdirectories just for this. > > In theory cabal could support this on older GHC versions by copying all of the > files to a working dir in dist with the expected layout on older GHCs. > > That would enable this to get much greater penetration more quickly. I'd really not want that people start putting ghc-options: -isrc=... into their cabal files. That'd make them irrecoverably ghc-specific, as no other tool will know how to process the files unless it reads ghc-options. I'm +1 on adding support for this to cabal. Then the mechanism cabal uses to achieve this is just that ? an implementation detail. And this new -i syntax can become one of such mechanisms. But cabal support should really come first, so that people aren't tempted by ghc-specific solutions. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From spam at scientician.net Fri Apr 25 17:02:10 2014 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 25 Apr 2014 19:02:10 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: References: <535A6065.1000606@gmail.com> <535A86E7.6010001@gmail.com> Message-ID: On 2014-04-25 18:52, Edward Kmett wrote: > I check out and work on projects on a bunch of machines, so it is important that I > can just pull with git and go. AFAIK, git doesn't understand them won't build symlinks > for me, so it'd just become another setup step for very marginal benefit, and another > thing to .gitignore. Git handles symlinks just fine. (Unless you're on Windows, I guess. I have no idea what it does there.) Regards, From sol at typeful.net Fri Apr 25 17:34:13 2014 From: sol at typeful.net (Simon Hengel) Date: Sat, 26 Apr 2014 01:34:13 +0800 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <20140425173353.GA8391@x200> > I want to propose something really simple that would avoid this > problem with minimal additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc > will look for the module Graphics.UI.Gtk.Button in src/Button.hs, > rather than src/Graphics/UI/Gtk/Button.hs. The source file itself > is unchanged: it still begins with "module Graphics.UI.Gtk.Button > ...". My initial reaction is "not so excited". Personally, I favor convention over configuration + it makes tooling more complicated. But my personal preferences aside: - Will this lead to further fragmentation in the community (some will like it / some will hate it)? - If the paths are too complicated for a library author to manage, maybe that is an indicator that the imports are too complicate to manage for a user of that library, too? Cheers, Simon From alain.odea at gmail.com Fri Apr 25 18:56:40 2014 From: alain.odea at gmail.com (Alain O'Dea) Date: Fri, 25 Apr 2014 18:56:40 +0000 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <458D5DAF-3CA6-480E-8BC6-A13EB6000014@gmail.com> References: <535A6065.1000606@gmail.com> <458D5DAF-3CA6-480E-8BC6-A13EB6000014@gmail.com> Message-ID: -1 for me. In case that was unclear. On 25 April 2014 14:57, Alain O'Dea wrote: > I have trouble with this as it breaks expectations around directory > structure mirroring the module hierarchy. > > I would be very confused reading the source code of a project that availed > of this feature as it would break my expectations of how to navigate to > source files based on their module hierarchy. > > I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah > etc., but changing this may break the tool's ability to provide jump to > symbol. > > I imagine other unforeseen challenges with source dependency analysis > elsewhere in the GHC toolchain may also arise if they assume that the > directory layout reflects the module hierarchy. The Java toolchain > certainly falls over when the corresponding package-flattening trick is > performed on a Java codebase. The workarounds are viral and wind up > complicating builds considerably. > > I could also be totally out to lunch here. > > > On Apr 25, 2014, at 13:17, Simon Marlow wrote: > > > > I want to propose a simple change to the -i flag for finding source > files. The problem we often have is that when you're writing code for a > library that lives deep in the module hierarchy, you end up needing a deep > directory structure, e.g. > > > > src/ > > Graphics/ > > UI/ > > Gtk/ > > Button.hs > > Label.hs > > ... > > > > where the top few layers are all empty. There have been proposals of > elaborate solutions for this in the past (module grafting etc.), but I want > to propose something really simple that would avoid this problem with > minimal additional complexity: > > > > ghc -iGraphics.UI.Gtk=src > > > > the meaning of this flag is that when searching for modules, ghc will > look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than > src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it > still begins with "module Graphics.UI.Gtk.Button ...". > > > > The implementation is only a few lines in the Finder (and probably > rather more in the manual and testsuite), but I wanted to get a sense of > whether people thought this would be a good idea, or if there's a better > alternative before I push it. > > > > Pros: > > > > - simple implementation (but Cabal needs mods, see below) > > - solves the deep directory problem > > > > Cons: > > > > - It makes the rules about finding files a bit more complicated. > > People need to find source files too, not just compilers. > > - packages that want to be compatible with older compilers can't > > use it yet. > > - you can't use '=' in a source directory name (but we could pick > > a different syntax if necessary) > > - It won't work for Cabal packages until Cabal is modified to > > support it (PreProcess and SrcDist and perhaps Haddock are the only > > places affected, I think) > > - Hackage will need to reject packages that use this feature without > > also specifying ghc >= 7.10 and some cabal-version too. > > - Are there other tools/libraries that will need changes? Leksah? > > > > Cheers, > > Simon > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Apr 25 19:50:36 2014 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 25 Apr 2014 21:50:36 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: On 2014-04-25 15:17, Simon Marlow wrote: [--snip--] -1 From malcolm.wallace at me.com Fri Apr 25 20:26:55 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 25 Apr 2014 21:26:55 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <41AF9575-A576-42E3-9F90-97614039ED6A@me.com> On 25 Apr 2014, at 14:17, Simon Marlow wrote: > The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, where the top few layers are all empty. I don't see how this is a problem at all. Navigating the "vacuous" structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: cabal, hoogle, haddock, happy, alex, hat, hsc2hs and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Regards, Malcolm From spam at scientician.net Sat Apr 26 06:54:32 2014 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 26 Apr 2014 08:54:32 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: On 2014-04-25 15:17, Simon Marlow wrote: > I want to propose a simple change to the -i flag for finding source > files. The problem we often have is that when you're writing code for a > library that lives deep in the module hierarchy, you end up needing a > deep directory structure, e.g. > -1, too complicated for very little benefit From Henrik.Nilsson at nottingham.ac.uk Sat Apr 26 11:18:56 2014 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Sat, 26 Apr 2014 12:18:56 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <535B9620.7030603@nottingham.ac.uk> Hi, > I want to propose a simple change to the -i flag for finding source > files. The problem we often have is that when you're writing code > for a library that lives deep in the module hierarchy, you end up > needing a deep directory structure, e.g. +1 from me. The deep file system hierarchies imposed by the assumption that hierarchical module names need to be matched by a hierarchical directory structure has always bothered me (well, since hierarchical modules were introduced into Haskell some 15 years ago). In part because I do find it inconvenient, even if navigation arguably is not too hard, but more importantly because I think that language naming conventions in general should be as decoupled as possible from naming conventions of file systems/the mapping to how source code happen to be stored and organised on any particular system. While I do acknowledge the pragmatical convenience of essentially one-to-one mappings between module and file names, I think this proposal would be a step in the right direction, if feasible. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From eir at cis.upenn.edu Sun Apr 27 05:39:24 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 27 Apr 2014 01:39:24 -0400 Subject: Type/type class information in GHC plugin In-Reply-To: <53598415.4050700@gmail.com> References: <53598376.8050304@gmail.com> <53598415.4050700@gmail.com> Message-ID: <1A9E8640-AF83-474F-88B4-40C2E0EA79AE@cis.upenn.edu> Hello Shen, I?m not sure if I?m answering exactly what you?re asking, but perhaps this can move you in the right direction: - To apply an expression to some types, you can use mkTyApps, in the CoreSyn module. The type of that function (Expr b -> [Type] -> Expr b) should be self-explanatory. - To get the instance environments (where all class instances are stored), use tcGetInstEnvs, in the Inst module. - Then, to get the actual dictionary, you can do the lookup with lookupInstEnv, in the InstEnv module. Does this move you in the right direction? Richard On Apr 24, 2014, at 5:37 PM, Shen Chen Xu wrote: > Hello everyone, > > I would like to write a GHC plugin which adds wrapper to functions. Say I have > a function > > addWrapper :: Ord a => (a -> b) -> a -> b > > which is supposed to transform (assuming the argument is in the Ord class) > > foo = \ x -> ... > > into > > foo = addWrapper (\ x -> ...) > > This works fine if I'm only interested in wrapping functions of type Int -> > Int, in which case I make addWrapper to also have type > > addWrapper :: (Int -> Int) -> Int -> Int > > and use mkCoreApp to apply addWrapper to the right hand side. > > However, if I want it to be polymorphic as described above, the transformed GHC > Core for an Int -> Int function should look like > > foo = addHook @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fOrdInt (\ x -> ...) > > My question is, given the right hand side of foo, how do I construct the > type/type class information inside Core shown above? > > Cheers, > Shen > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From voldermort at hotmail.com Sun Apr 27 11:14:00 2014 From: voldermort at hotmail.com (harry) Date: Sun, 27 Apr 2014 04:14:00 -0700 (PDT) Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: References: Message-ID: <1398597240841-5748556.post@n5.nabble.com> John Lato-2 wrote > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled Are you able to use template haskell (and qusiquoting) with this? Don't they need dynamic libs? -- View this message in context: http://haskell.1045720.n5.nabble.com/how-to-compile-non-dynamic-ghc-7-8-2-tp5748418p5748556.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From austin at well-typed.com Sun Apr 27 13:14:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 27 Apr 2014 08:14:20 -0500 Subject: Removing -fext-core Message-ID: Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Sun Apr 27 16:10:32 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 27 Apr 2014 12:10:32 -0400 Subject: Removing -fext-core In-Reply-To: References: Message-ID: <42DE22FA-F1D7-4709-A4FF-2952EF3768E1@cis.upenn.edu> +1 from me I?ve been meaning to say essentially the same thing as you just did. We all seem to concentrate on *adding* things to GHC; it?s a bit refreshing to consider *removing* something. Echoing Austin somewhat: - Anyone using external core is either working with an old GHC or is kludging quite a bit, as it?s horribly rotten compared to ?internal? core. (For what it?s worth, I?m responsible for much of the rot. When I started working on Core, external core was just enough rotten already that I didn?t feel compelled to keep it up to date... but now it?s in a sorry state, indeed.) - With the GHC API, the ability for plugins, and HERMIT[1], I think external core?s utility has been eclipsed. - GHC actually contains a parser for external core, which is type-checked during compilation, but its functions are never actually called anywhere! This is a sure sign of Something Wrong. Richard [1]: http://www.ittc.ku.edu/csdl/fpg/software/hermit.html On Apr 27, 2014, at 9:14 AM, Austin Seipp wrote: > Hello all, > > Recently I was wondering something: is there any reason to keep > -fext-core around? In particular, it's been broken for a while at this > point, see GHC bug #5630[1] > > As far as I'm aware there really aren't any users of it still around > these days, at least none working with a modern GHC. And it seems like > if people were to need access to Core, they could use a plugin or some > such to get direct access to what they want. > > Simon mentioned removing ExtCore in face of replacing it with IfaceSyn > in the compiler. I'm not entirely sure how much work that would be to > bring it all up to scratch if people needed it, but maybe it's worth > thinking about. > > One other issue is a notion of semantics which is present in External > Core, but we also now have a documented semantics for GHC's core > language as well (which has evolved quite a bit), so I don't know how > much that matters. > > So long story short: I don't think anyone is using it, maintaining it, > and it seems subsumed by more recent events. > > Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, > unless someone is willing to step up and really maintain it. If you're > using it, you should probably speak up soon I'd imagine... > > [1] https://ghc.haskell.org/trac/ghc/ticket/5630 > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From jwlato at gmail.com Sun Apr 27 23:00:46 2014 From: jwlato at gmail.com (John Lato) Date: Sun, 27 Apr 2014 16:00:46 -0700 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: References: <20140425123624.GA7497@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: Hi Carter, cabal-install-1.20.0.0, using Cabal 1.20.0.0. But this also happened IIRC with just ghc, no libraries installed, and no cabal anywhere on the path. In any case, thus far the worst behavior I've seen from a too-old cabal is a compile failure, not a core dump :) On Fri, Apr 25, 2014 at 9:47 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > @john, what version of cabal-install were you using? (i realize you're > probably using the right one, but worth asking :) ) > > > On Fri, Apr 25, 2014 at 12:25 PM, John Lato wrote: > >> >> On Apr 25, 2014 5:36 AM, "Bertram Felgenhauer" < >> bertram.felgenhauer at googlemail.com> wrote: >> > >> > John Lato wrote: >> > > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on >> 64-bit >> > > linux). I downloaded the source tarball, added >> > > >> > > DYNAMIC_GHC_PROGRAMS = NO >> > >> > I've had success with setting both >> > >> > DYNAMIC_BY_DEFAULT = NO >> > DYNAMIC_GHC_PROGRAMS = NO >> > >> > and removing the 'dyn' way altogether from GhcLibWays by setting >> > GhcLibWays = v explicitely. I expect that the latter is optional; >> > my goal was only to speed up the build. >> > >> > (The lines were copied from the perf-cross settings.) >> >> I tried disabling dynamicByDefault also, but that didn't help. It may be >> a problem with lib ways though, I'll try that. >> >> Thanks, John >> >> > Cheers, >> > >> > Bertram >> > _______________________________________________ >> > Glasgow-haskell-users mailing list >> > Glasgow-haskell-users at haskell.org >> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Apr 28 08:26:23 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 09:26:23 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <20140425165712.GB29470@sniper> References: <535A6065.1000606@gmail.com> <20140425165712.GB29470@sniper> Message-ID: <535E10AF.10807@gmail.com> On 25/04/2014 17:57, Roman Cheplyaka wrote: > * Edward Kmett [2014-04-25 11:22:46-0400] >> +1 from me. I have a lot of projects that suffer with 4 levels of vacuous >> subdirectories just for this. >> >> In theory cabal could support this on older GHC versions by copying all of the >> files to a working dir in dist with the expected layout on older GHCs. >> >> That would enable this to get much greater penetration more quickly. > > I'd really not want that people start putting ghc-options: -isrc=... > into their cabal files. That'd make them irrecoverably ghc-specific, as no other > tool will know how to process the files unless it reads ghc-options. No, the idea would be to use hs-source-dirs like this: hs-source-dirs: A.B.C=src Cabal just passes this in a -i option to GHC, so it almost Just Works, except that Cabal needs to preprocess some source files so it needs to find them, and also sdist needs to find source files. Cheers, Simon > I'm +1 on adding support for this to cabal. Then the mechanism cabal uses to > achieve this is just that ? an implementation detail. And this new -i syntax can > become one of such mechanisms. > > But cabal support should really come first, so that people aren't tempted by > ghc-specific solutions. > > Roman > From marlowsd at gmail.com Mon Apr 28 08:33:47 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 09:33:47 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <41AF9575-A576-42E3-9F90-97614039ED6A@me.com> References: <535A6065.1000606@gmail.com> <41AF9575-A576-42E3-9F90-97614039ED6A@me.com> Message-ID: <535E126B.5010007@gmail.com> On 25/04/2014 21:26, Malcolm Wallace wrote: > > On 25 Apr 2014, at 14:17, Simon Marlow wrote: > >> The problem we often have is that when you're writing code for a library that lives deep in the module hierarchy, you end up needing a deep directory structure, where the top few layers are all empty. > > I don't see how this is a problem at all. Navigating the "vacuous" structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: > > cabal, hoogle, haddock, happy, alex, hat, hsc2hs So actually many of these tools don't need to map module names to source files, so they work unchanged. Only Cabal definitely needs changes, I'm not sure about hoogle and hat but I suspect they would be fine. > and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Fair enough :) Cheers, Simon > > Regards, > Malcolm > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From marlowsd at gmail.com Mon Apr 28 08:35:11 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 28 Apr 2014 09:35:11 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535A6065.1000606@gmail.com> References: <535A6065.1000606@gmail.com> Message-ID: <535E12BF.2040008@gmail.com> Thanks for all the feedback. Clearly opinion is divided on this one, so I'll sit on it and think it through some more. Cheers, Simon On 25/04/2014 14:17, Simon Marlow wrote: > I want to propose a simple change to the -i flag for finding source > files. The problem we often have is that when you're writing code for a > library that lives deep in the module hierarchy, you end up needing a > deep directory structure, e.g. > > src/ > Graphics/ > UI/ > Gtk/ > Button.hs > Label.hs > ... > > where the top few layers are all empty. There have been proposals of > elaborate solutions for this in the past (module grafting etc.), but I > want to propose something really simple that would avoid this problem > with minimal additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc will > look for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than > src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it > still begins with "module Graphics.UI.Gtk.Button ...". > > The implementation is only a few lines in the Finder (and probably > rather more in the manual and testsuite), but I wanted to get a sense of > whether people thought this would be a good idea, or if there's a better > alternative before I push it. > > Pros: > > - simple implementation (but Cabal needs mods, see below) > - solves the deep directory problem > > Cons: > > - It makes the rules about finding files a bit more complicated. > People need to find source files too, not just compilers. > - packages that want to be compatible with older compilers can't > use it yet. > - you can't use '=' in a source directory name (but we could pick > a different syntax if necessary) > - It won't work for Cabal packages until Cabal is modified to > support it (PreProcess and SrcDist and perhaps Haddock are the only > places affected, I think) > - Hackage will need to reject packages that use this feature without > also specifying ghc >= 7.10 and some cabal-version too. > - Are there other tools/libraries that will need changes? Leksah? > > Cheers, > Simon From roma at ro-che.info Mon Apr 28 08:40:41 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 28 Apr 2014 11:40:41 +0300 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <535E10AF.10807@gmail.com> References: <535A6065.1000606@gmail.com> <20140425165712.GB29470@sniper> <535E10AF.10807@gmail.com> Message-ID: <20140428084041.GA29401@sniper> * Simon Marlow [2014-04-28 09:26:23+0100] > On 25/04/2014 17:57, Roman Cheplyaka wrote: > >* Edward Kmett [2014-04-25 11:22:46-0400] > >>+1 from me. I have a lot of projects that suffer with 4 levels of vacuous > >>subdirectories just for this. > >> > >>In theory cabal could support this on older GHC versions by copying all of the > >>files to a working dir in dist with the expected layout on older GHCs. > >> > >>That would enable this to get much greater penetration more quickly. > > > >I'd really not want that people start putting ghc-options: -isrc=... > >into their cabal files. That'd make them irrecoverably ghc-specific, as no other > >tool will know how to process the files unless it reads ghc-options. > > No, the idea would be to use hs-source-dirs like this: > > hs-source-dirs: A.B.C=src > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > except that Cabal needs to preprocess some source files so it needs to find > them, and also sdist needs to find source files. In that case, I'm in favour of this proposal. Please consider the reversed syntax instead: hs-source-dirs: src=A.B.C I find it more intuitive, because A.B.C becomes sort of an optional parameter, the empty prefix being its default value. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From simonpj at microsoft.com Mon Apr 28 09:09:04 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 28 Apr 2014 09:09:04 +0000 Subject: Removing -fext-core In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> In principle I think it's a pity to lose External Core. It provides an interface to GHC that is based on the simplest possibly connector (a text file), and allows GHC's front end or back end to be used by other systems written in different languages. However, as you say, it has received no love for many years. I have repeatedly sought someone to support and maintain External Core, but no one has stepped forward. That doesn't mean that no one is using it! But the absence of bug reports, given how much it has bit-rotted, is a strong indicator that no one is. So I'd like hear from our users, but I won't stand in the way of removing it. Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces at haskell.org] On Behalf Of Austin Seipp | Sent: 27 April 2014 14:14 | To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org | Subject: Removing -fext-core | | Hello all, | | Recently I was wondering something: is there any reason to keep -fext- | core around? In particular, it's been broken for a while at this point, | see GHC bug #5630[1] | | As far as I'm aware there really aren't any users of it still around | these days, at least none working with a modern GHC. And it seems like | if people were to need access to Core, they could use a plugin or some | such to get direct access to what they want. | | Simon mentioned removing ExtCore in face of replacing it with IfaceSyn | in the compiler. I'm not entirely sure how much work that would be to | bring it all up to scratch if people needed it, but maybe it's worth | thinking about. | | One other issue is a notion of semantics which is present in External | Core, but we also now have a documented semantics for GHC's core | language as well (which has evolved quite a bit), so I don't know how | much that matters. | | So long story short: I don't think anyone is using it, maintaining it, | and it seems subsumed by more recent events. | | Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, | unless someone is willing to step up and really maintain it. If you're | using it, you should probably speak up soon I'd imagine... | | [1] https://ghc.haskell.org/trac/ghc/ticket/5630 | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users at haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From conrad at metadecks.org Mon Apr 28 11:23:56 2014 From: conrad at metadecks.org (Conrad Parker) Date: Mon, 28 Apr 2014 21:23:56 +1000 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <20140428084041.GA29401@sniper> References: <535A6065.1000606@gmail.com> <20140425165712.GB29470@sniper> <535E10AF.10807@gmail.com> <20140428084041.GA29401@sniper> Message-ID: On 28 April 2014 18:40, Roman Cheplyaka wrote: > * Simon Marlow [2014-04-28 09:26:23+0100] > > No, the idea would be to use hs-source-dirs like this: > > > > hs-source-dirs: A.B.C=src > > > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > > except that Cabal needs to preprocess some source files so it needs to > find > > them, and also sdist needs to find source files. > > In that case, I'm in favour of this proposal. > > Please consider the reversed syntax instead: > > hs-source-dirs: src=A.B.C > > I find it more intuitive, because A.B.C becomes sort of an optional > parameter, > the empty prefix being its default value. > src=A.B.C implies a 1-1 mapping between a srcdir and a module root, whereas A.B.C=src allows different modules (eg. all a project) to live in the same dir: Graphics.UI.Gtk=src System.IO.EEG=src Game.Flappy2048=src Conrad. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Apr 28 11:47:37 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 28 Apr 2014 12:47:37 +0100 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <20140428084041.GA29401@sniper> References: <535A6065.1000606@gmail.com> <20140425165712.GB29470@sniper> <535E10AF.10807@gmail.com> <20140428084041.GA29401@sniper> Message-ID: Coming from Scala where I can basically structure my directory sources the way I want I got a bit frustrated by Haskell rigidity here. So definitely a +1, and I agree cabal support is quite important. OTOH, I don't think Haskell should go in the way of allowing 'any' structure (like scala), but being able to have shortcut like that would be definitely beneficial. Also, I don't think integrating such feature will be an issue for the text editors "jump to declaration" feature, as they should usually use `tags` files. On 28 April 2014 09:40, Roman Cheplyaka wrote: > * Simon Marlow [2014-04-28 09:26:23+0100] > > On 25/04/2014 17:57, Roman Cheplyaka wrote: > > >* Edward Kmett [2014-04-25 11:22:46-0400] > > >>+1 from me. I have a lot of projects that suffer with 4 levels of > vacuous > > >>subdirectories just for this. > > >> > > >>In theory cabal could support this on older GHC versions by copying > all of the > > >>files to a working dir in dist with the expected layout on older GHCs. > > >> > > >>That would enable this to get much greater penetration more quickly. > > > > > >I'd really not want that people start putting ghc-options: -isrc=... > > >into their cabal files. That'd make them irrecoverably ghc-specific, as > no other > > >tool will know how to process the files unless it reads ghc-options. > > > > No, the idea would be to use hs-source-dirs like this: > > > > hs-source-dirs: A.B.C=src > > > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > > except that Cabal needs to preprocess some source files so it needs to > find > > them, and also sdist needs to find source files. > > In that case, I'm in favour of this proposal. > > Please consider the reversed syntax instead: > > hs-source-dirs: src=A.B.C > > I find it more intuitive, because A.B.C becomes sort of an optional > parameter, > the empty prefix being its default value. > > Roman > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Apr 28 12:10:19 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 28 Apr 2014 14:10:19 +0200 Subject: RFC: changes to -i flag for finding source files In-Reply-To: <41AF9575-A576-42E3-9F90-97614039ED6A@me.com> References: <535A6065.1000606@gmail.com> <41AF9575-A576-42E3-9F90-97614039ED6A@me.com> Message-ID: 2014-04-25 22:26 GMT+02:00 Malcolm Wallace : > [...] The feature seems like a very low power-to-weight ratio, so -1 from me. -1 from me, for the same reasons. From marlowsd at gmail.com Tue Apr 29 17:36:46 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 29 Apr 2014 18:36:46 +0100 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: References: Message-ID: <535FE32E.7020406@gmail.com> On 25/04/2014 02:15, John Lato wrote: > Hello, > > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on > 64-bit linux). I downloaded the source tarball, added > > DYNAMIC_GHC_PROGRAMS = NO > > to mk/build.mk , and did ./configure && ./make. > > ghc builds and everything seems to work (cabal installed a bunch of > packages, ghci seems to work), however whenever I try to run Setup.hs > dynamically (either 'runghc Setup.hs configure' or loading it with ghci > and executing 'main') it dumps core. Compiling Setup.hs works, and > nothing else has caused ghci to crash either (this email is a literate > haskell file equivalent to Setup.hs). > > Building with DYNAMIC_GHC_PROGRAMS = YES works properly. > > With that in mind, I have a few questions: > > How should I compile a non-dynamic ghc? > Is this a bug in ghc? I think you are running into this: https://ghc.haskell.org/trac/ghc/ticket/8935 It took me a *long* time to track that one down. I still don't know what the root cause is, because I don't understand the system linker's behaviour here. Given that other people are running into this, we ought to milestone it for 7.8.3 and do something about it. Cheers, Simon From dagitj at gmail.com Tue Apr 29 21:47:53 2014 From: dagitj at gmail.com (Jason Dagit) Date: Tue, 29 Apr 2014 14:47:53 -0700 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: <535FE32E.7020406@gmail.com> References: <535FE32E.7020406@gmail.com> Message-ID: On Tue, Apr 29, 2014 at 10:36 AM, Simon Marlow wrote: > On 25/04/2014 02:15, John Lato wrote: > >> Hello, >> >> I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on >> 64-bit linux). I downloaded the source tarball, added >> >> DYNAMIC_GHC_PROGRAMS = NO >> >> to mk/build.mk , and did ./configure && ./make. >> >> >> ghc builds and everything seems to work (cabal installed a bunch of >> packages, ghci seems to work), however whenever I try to run Setup.hs >> dynamically (either 'runghc Setup.hs configure' or loading it with ghci >> and executing 'main') it dumps core. Compiling Setup.hs works, and >> nothing else has caused ghci to crash either (this email is a literate >> haskell file equivalent to Setup.hs). >> >> Building with DYNAMIC_GHC_PROGRAMS = YES works properly. >> >> With that in mind, I have a few questions: >> >> How should I compile a non-dynamic ghc? >> Is this a bug in ghc? >> > > I think you are running into this: https://ghc.haskell.org/trac/ > ghc/ticket/8935 > > It took me a *long* time to track that one down. I still don't know what > the root cause is, because I don't understand the system linker's behaviour > here. I just updated the ticket. I think I know what is going on so I added a possible explanation. I'm not sure how you want to fix it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Apr 29 22:02:53 2014 From: conal at conal.net (Conal Elliott) Date: Tue, 29 Apr 2014 15:02:53 -0700 Subject: GHC rewrite rules and constructor wrappers? Message-ID: I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like > "reify/(:<)" reifyEP (:<) = kPrim VecSP This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire. Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC. -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Wed Apr 30 00:27:35 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 29 Apr 2014 17:27:35 -0700 Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: <535FE32E.7020406@gmail.com> References: <535FE32E.7020406@gmail.com> Message-ID: Hi Simon, Thanks very much for this response. I believe you're correct; ghc -e 'System.Environment.getEnvironment' segfaults with my ghc build. John On Tue, Apr 29, 2014 at 10:36 AM, Simon Marlow wrote: > On 25/04/2014 02:15, John Lato wrote: > >> Hello, >> >> I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on >> 64-bit linux). I downloaded the source tarball, added >> >> DYNAMIC_GHC_PROGRAMS = NO >> >> to mk/build.mk , and did ./configure && ./make. >> >> >> ghc builds and everything seems to work (cabal installed a bunch of >> packages, ghci seems to work), however whenever I try to run Setup.hs >> dynamically (either 'runghc Setup.hs configure' or loading it with ghci >> and executing 'main') it dumps core. Compiling Setup.hs works, and >> nothing else has caused ghci to crash either (this email is a literate >> haskell file equivalent to Setup.hs). >> >> Building with DYNAMIC_GHC_PROGRAMS = YES works properly. >> >> With that in mind, I have a few questions: >> >> How should I compile a non-dynamic ghc? >> Is this a bug in ghc? >> > > I think you are running into this: https://ghc.haskell.org/trac/ > ghc/ticket/8935 > > It took me a *long* time to track that one down. I still don't know what > the root cause is, because I don't understand the system linker's behaviour > here. Given that other people are running into this, we ought to milestone > it for 7.8.3 and do something about it. > > Cheers, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Wed Apr 30 06:10:08 2014 From: ganesh at earth.li (Ganesh Sittampalam) Date: Wed, 30 Apr 2014 07:10:08 +0100 Subject: [core libraries] Re: Tightening up on inferred type signatures In-Reply-To: <87fvl3amvp.fsf@ta.scs.stanford.edu> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> <87ha5m45fm.fsf@ta.scs.stanford.edu> <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> <87fvl3amvp.fsf@ta.scs.stanford.edu> Message-ID: <536093C0.1020103@earth.li> On 23/04/2014 20:04, dm-list-haskell-libraries at scs.stanford.edu wrote: > Edward Kmett writes: > >> You can wind up in perfectly legitimate situations where the name for the >> type you are working with isn't in scope, but where you can write a >> combinator that would infer to have that type. I'd hate to lose that. >> >> It is admittedly of marginal utility at first glance, but there are some >> tricks that actually need it, and it can also arise if a type synonym >> expands to a type that isn't exported or brought into scope, so trying to >> push this line of reasoning too far I is possibly not too productive. > > Good point. In particular, it's not weird at all want to export type > synonyms on their own, particularly where ghost type parameters are used > to select between only a few cases. Consider something like this > (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh From ekmett at gmail.com Wed Apr 30 06:47:22 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 30 Apr 2014 02:47:22 -0400 Subject: [core libraries] Re: Tightening up on inferred type signatures In-Reply-To: <536093C0.1020103@earth.li> References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> <87ha5m45fm.fsf@ta.scs.stanford.edu> <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> <87fvl3amvp.fsf@ta.scs.stanford.edu> <536093C0.1020103@earth.li> Message-ID: Not sure. An even simpler case is something like exporting a Traversal but not exporting Data.Traversable, which appears in the expansion, etc. These sorts of things happen in code using lens. Older versions of lens didn't export all of the types needed to write out the type signature long hand without extra imports, just to avoid cluttering the namespace. -Edward On Wed, Apr 30, 2014 at 2:10 AM, Ganesh Sittampalam wrote: > On 23/04/2014 20:04, dm-list-haskell-libraries at scs.stanford.edu wrote: > > Edward Kmett writes: > > > >> You can wind up in perfectly legitimate situations where the name for > the > >> type you are working with isn't in scope, but where you can write a > >> combinator that would infer to have that type. I'd hate to lose that. > >> > >> It is admittedly of marginal utility at first glance, but there are some > >> tricks that actually need it, and it can also arise if a type synonym > >> expands to a type that isn't exported or brought into scope, so trying > to > >> push this line of reasoning too far I is possibly not too productive. > > > > Good point. In particular, it's not weird at all want to export type > > synonyms on their own, particularly where ghost type parameters are used > > to select between only a few cases. Consider something like this > > (inspired by postgresql-orm): > > Is there an abstraction being protected by only exporting the type > synonym in cases like this? > > Cheers, > > Ganesh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Apr 30 06:59:29 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 30 Apr 2014 02:59:29 -0400 Subject: [core libraries] Re: Tightening up on inferred type signatures In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A555F25@DB3PRD3001MB020.064d.mgd.msft.net> <87ha5m45fm.fsf@ta.scs.stanford.edu> <618BE556AADD624C9C918AA5D5911BEF0A557A96@DB3PRD3001MB020.064d.mgd.msft.net> <87fvl3amvp.fsf@ta.scs.stanford.edu> <536093C0.1020103@earth.li> Message-ID: Er.. my mistake. Control.Applicative. That is what it is we don't re-export that is used in Traversal. =) On Wed, Apr 30, 2014 at 2:47 AM, Edward Kmett wrote: > Not sure. > > An even simpler case is something like exporting a Traversal but not > exporting Data.Traversable, which appears in the expansion, etc. > > These sorts of things happen in code using lens. Older versions of lens > didn't export all of the types needed to write out the type signature long > hand without extra imports, just to avoid cluttering the namespace. > > -Edward > > > On Wed, Apr 30, 2014 at 2:10 AM, Ganesh Sittampalam wrote: > >> On 23/04/2014 20:04, dm-list-haskell-libraries at scs.stanford.edu wrote: >> > Edward Kmett writes: >> > >> >> You can wind up in perfectly legitimate situations where the name for >> the >> >> type you are working with isn't in scope, but where you can write a >> >> combinator that would infer to have that type. I'd hate to lose that. >> >> >> >> It is admittedly of marginal utility at first glance, but there are >> some >> >> tricks that actually need it, and it can also arise if a type synonym >> >> expands to a type that isn't exported or brought into scope, so trying >> to >> >> push this line of reasoning too far I is possibly not too productive. >> > >> > Good point. In particular, it's not weird at all want to export type >> > synonyms on their own, particularly where ghost type parameters are used >> > to select between only a few cases. Consider something like this >> > (inspired by postgresql-orm): >> >> Is there an abstraction being protected by only exporting the type >> synonym in cases like this? >> >> Cheers, >> >> Ganesh >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Wed Apr 30 08:18:17 2014 From: voldermort at hotmail.com (harry) Date: Wed, 30 Apr 2014 01:18:17 -0700 (PDT) Subject: how to compile non-dynamic ghc-7.8.2 ? In-Reply-To: <1398597240841-5748556.post@n5.nabble.com> References: <1398597240841-5748556.post@n5.nabble.com> Message-ID: <1398845897845-5748865.post@n5.nabble.com> John Lato-2 wrote > I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled Are you able to use template haskell (and qusiquoting) with this? Don't they need dynamic libs? -- View this message in context: http://haskell.1045720.n5.nabble.com/how-to-compile-non-dynamic-ghc-7-8-2-tp5748418p5748865.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. From austin at well-typed.com Wed Apr 30 13:36:06 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 30 Apr 2014 08:36:06 -0500 Subject: Removing -fext-core In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: For people keeping score, I created a branch with this already done the other day: https://github.com/ghc/ghc/tree/wip/kill-extcore Again, unless someone speaks up *real* soon, I'm probably going to get rid of it before the end of the week - so your timeframe is something like 72 hours to make a peep before it goes away.... On Mon, Apr 28, 2014 at 4:09 AM, Simon Peyton Jones wrote: > In principle I think it's a pity to lose External Core. It provides an interface to GHC that is based on the simplest possibly connector (a text file), and allows GHC's front end or back end to be used by other systems written in different languages. > > However, as you say, it has received no love for many years. I have repeatedly sought someone to support and maintain External Core, but no one has stepped forward. That doesn't mean that no one is using it! But the absence of bug reports, given how much it has bit-rotted, is a strong indicator that no one is. > > So I'd like hear from our users, but I won't stand in the way of removing it. > > Simon > > > | -----Original Message----- > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- > | bounces at haskell.org] On Behalf Of Austin Seipp > | Sent: 27 April 2014 14:14 > | To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org > | Subject: Removing -fext-core > | > | Hello all, > | > | Recently I was wondering something: is there any reason to keep -fext- > | core around? In particular, it's been broken for a while at this point, > | see GHC bug #5630[1] > | > | As far as I'm aware there really aren't any users of it still around > | these days, at least none working with a modern GHC. And it seems like > | if people were to need access to Core, they could use a plugin or some > | such to get direct access to what they want. > | > | Simon mentioned removing ExtCore in face of replacing it with IfaceSyn > | in the compiler. I'm not entirely sure how much work that would be to > | bring it all up to scratch if people needed it, but maybe it's worth > | thinking about. > | > | One other issue is a notion of semantics which is present in External > | Core, but we also now have a documented semantics for GHC's core > | language as well (which has evolved quite a bit), so I don't know how > | much that matters. > | > | So long story short: I don't think anyone is using it, maintaining it, > | and it seems subsumed by more recent events. > | > | Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, > | unless someone is willing to step up and really maintain it. If you're > | using it, you should probably speak up soon I'd imagine... > | > | [1] https://ghc.haskell.org/trac/ghc/ticket/5630 > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users at haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From johan.tibell at gmail.com Wed Apr 30 13:39:29 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 30 Apr 2014 15:39:29 +0200 Subject: Removing -fext-core In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF0A576756@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: