- ghc-devs - Haskell.org

RE: The suggested redundant import solution doesn't work for explicit import lists
by Simon Peyton Jones 26 Feb '15

26 Feb '15

OK. I've created a ticket https://ghc.haskell.org/trac/ghc/ticket/10117 In fact there is a pretty good specification here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/UnusedImports So back to you: based on the existing, can you think of a variant that would work better? Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 February 2015 12:00 | To: Simon Peyton Jones | Cc: Herbert Valerio Riedel; Johan Tibell; Edward Kmett; Austin Seipp | Subject: Re: The suggested redundant import solution doesn't work for | explicit import lists | | Simon, | | The problem: | | trying to avoid redundant-import warnings due symbols having moved to | 'Prelude' due to AMP/FTP w/o CPP usage | | e.g. | | import Control.Applicative (Applicative) | | foo :: Applicative f => ... | foo = ... | | now warns that 'Applicative' is redundant, as it's exported from | 'Prelude' now. 'Monoid' is another such example that's now re-exported | from 'Prelude' (but wasn't before GHC 7.10). | | | One thing that happens to work is the trick shown at | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f...isredundant | i.e. | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid | import Data.Word | import Prelude | | as in that case, 'Prelude' is explicitly imported last, and so GHC | doesn't warn about Data.{Word,Monoid} being redundant (due to the way | the redundancy-check is implemented in GHC) | | However, if the example above is rewritten as | | module Foo (Int, Word, Monoid(..)) where | | import Data.Monoid (Monoid(..)) | import Data.Word (Word) | import Prelude | | GHC would warn, as it handles import-listed symbols differently than | wildcard imports... | | and the question is, whether we can easily get the latter example to | become warning free as well w/o risking breakages elsewhere... | | ...is it clearer now what I'm suggesting? | | Cheers, | hvr | | On 2015-02-24 at 12:50:35 +0100, Simon Peyton Jones wrote: | > I'm sorry, but can someone re-articulate the question? I'm deep | underwater, so reluctant to reverse-engineer the question from the | thread. | > I think you are asking for some feature. But I'm not sure what the | spec is. | > | > Simon | > | > | -----Original Message----- | > | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | > | Sent: 24 February 2015 11:29 | > | To: Johan Tibell | > | Cc: Edward Kmett; Simon Peyton Jones; Austin Seipp | > | Subject: Re: The suggested redundant import solution doesn't work | > | for explicit import lists | > | | > | Johan, | > | | > | You're right, I'm afraid the Prelude-trick doesn't work well with | > | import-lists... not sure though if it's worth the risk to tweak | GHC | > | 7.10.1's redundant-warning detection to make it work here too... | > | | > | @SPJ, any comments? | > | | > | for more context: | > | | > | - | > | | https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimporto | f.. | > | .isredundant | > | - | > | | http://www.reddit.com/r/haskell/comments/2wx64g/ghc_710_will_use_pla | > | n_ftp | > | /covdas0 | > | | > | Cheers, | > | hvr | > | | > | On 2015-02-24 at 11:47:30 +0100, Johan Tibell wrote: | > | > The suggested fix for unused imports resulting from the move of | e.g. | > | > Data.Monoid doesn't work when using explicit import lists: | > | > | > | > $ cat Test.hs | > | > module Test where | > | > | > | > import Data.Monoid (Monoid) | > | > import Prelude | > | > | > | > f :: Monoid a => a | > | > f = undefined | > | > $ ghc-7.10.0.20150123 -Wall /tmp/Test.hs | > | > [1 of 1] Compiling Test ( /tmp/Test.hs, /tmp/Test.o | ) | > | > | > | > /tmp/Test.hs:3:1: Warning: | > | > The import of ‘Data.Monoid’ is redundant | > | > except perhaps to import instances from ‘Data.Monoid’ | > | > To import instances alone, use: import Data.Monoid() | > | > | > | > It does work if you don't have an import list (bad idea) or use | > | qualified | > | > imports (good idea). | > | > | > | > -- Johan | > | | > | -- | > | "Elegance is not optional" -- Richard O'Keefe | | -- | "Elegance is not optional" -- Richard O'Keefe

2 1

Broken `cabal haddock --hoogle` with GHC 7.10
by Michael Snoyman 26 Feb '15

26 Feb '15

I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running `cabal haddock --hoogle` does not work. There seem to be two different issues open about it: https://github.com/haskell/haddock/issues/361 https://github.com/haskell/cabal/issues/2297 I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.

4 5

Out of action
by Simon Peyton Jones 25 Feb '15

25 Feb '15

Folks Just to say that I'm very silent right now because of the ICFP deadline on Friday. Probably no cycles for GHC until Monday at earliest. Simon

1 0

Re: [Haskell-cafe] PowerPC variants (GHC 7.8.3)
by Carter Schonwald 25 Feb '15

25 Feb '15

Hey Jon, I do know that some of the GHC dev team is probably best equipped to answer your question, i'm cc'ing the ghc dev and users lists so they can jump in and help! -Carter On Wed, Feb 25, 2015 at 7:11 AM, Jon Schneider <haskell(a)jschneider.net> wrote: > Good morning, > > We have a product with an MPC8544E we might want to target. Also known as > PowerQUICC and e500v2. The ABI is gnuspe rather than gnueabi. > > I have built a powerpc---ghc cross compiler but the thing stopping "hello > world" is a SIGILL happening in StgCRun.c where the stfd and lfd > instructions are used to stash registers. The e500 has different > instructions but that cannot be dropped in trivially because of offset > encoding Commenting these out fixes "hello world" though this surely only > scratches the surface of what would need doing. > > I notice that whereas ARMv5, v6 and v7 appear to be catered for along with > various knobs and whistles there appears to be no such thing for PowerPC. > > Is anybody else out there working on this area ? > > Jon > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

EvTerms and how they are used
by Jan Bracker 25 Feb '15

25 Feb '15

Hello, I am trying to use the new type checker plugins [1] that are implemented in head. When successful a plugin has to return a [(EvTerm, Ct)] for the solved constraints. The documentation on EvTerms is scarce [2,3,4] and I could not find papers that explain them (many talk about 'evidence', but they never get concrete). So far I have figured out that "EvDFunApp DFunId [Type] [EvTerm]" selects a certain instance to be used for a constraint, though I don't know what the list of EvTerms in the end is for. I am also a bit unclear on how the "[Type]" is used.If I turn on '-dcore-lint' I get errors. So I still seem to be using it wrong. I have also asked in IRC, but did not get a response to my question. I am sorry if this is the wrong mailing list to ask. If there is a more apropriate place just point it out. Best, Jan [1]: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker [2]: http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… [3]: http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/libraries/ghc-7.… [4]: http://haskell.inf.elte.hu/docs/7.11.20150225.noWin32/html/users_guide/comp…

2 1

Arrow Development
by Thomas Bereknyei 24 Feb '15

24 Feb '15

I am looking at the proc notation de-sugar and I see results like this when using a Free Arrow (mostly copied from [1]): line2 = proc n -> do Effect getURLSum *** Effect getURLSum -< n Seq [Pure ] (Seq [Pure ] (Seq [Pure ] (Seq [Pure ](Par <Effect > {Effect } ) ) ) ) while this is so much simpler: line2 = Effect getURLSum *** Effect getURLSum Par <Effect > {Effect } Those `Seq [Pure ]` sequences come from application of (.) and I have noticed many similar inefficiencies in the Arrow preprocessor. Eventually the goal would be to optimize when possible, for example I started looking into this in order to use `concurrently` for (***) when in IO. There was a rewrite mentioned here [2]. The deSugar/DsArrows.hs [3] looks convoluted. Any progress or work needed? Or are Arrows not used much and not worth the effort? [1] http://stackoverflow.com/questions/12001350/useful-operations-on-free-arrows [2]https://mail.haskell.org/pipermail/haskell-cafe/2013-August/109795.html [3]https://github.com/ghc/ghc/blob/master/compiler/deSugar/DsArrows.hs -Tom

3 3

Proposal: Turn on ScopedTypeVariables by default
by David Feuer 24 Feb '15

24 Feb '15

I know this will be controversial, because it can break (weird) code and because it's not Haskell 2010, but hey, you can't make brain salad without breaking a few heads. ScopedTypeVariables is just awesome for two fundamental reasons: 1. It lets you write type signatures for more things. 2. It lets you write more precise type signatures for many things. As a consequence of those two, 3. It helps you get much better error messages from the type checker. And for all that, 4. It's really easy to use. What do other people think?

5 4

Docs of the daily builds broken
by Joachim Breitner 24 Feb '15

24 Feb '15

Hi, while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data-C… yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html Additinally, the wiki page at https://ghc.haskell.org/trac/ghc/wiki/BuilderSummary does not list a point of contact for this (and I regularly forget these things. Was it Gabor?). Whoever runs this: Good job! Make sure you take the credit! :-) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

RE: GHC Type Inference
by Simon Peyton Jones 24 Feb '15

24 Feb '15

Marc For type-level literals, the man to talk to is Iavor Diatchki. He implemented the current system, and has been working on enhancements. I'm sure he'd welcome help! There's also quite an active sub-group (on ghc-devs) working on "plug-ins" for the type inference algorithm, aimed at allowing things like better arithmetic reasoning to be done without having to change GHC itself. Simon | -----Original Message----- | From: dongen [mailto:dongen@cs.ucc.ie] | Sent: 23 February 2015 10:54 | To: Simon Peyton Jones | Cc: ghc-devs(a)haskell.org | Subject: GHC Type Inference | | Dear Simon, | | | I am cc-ing _ghc-devs(a)haskell.org_ as requested on _ghc.haskell.org_. | | I hope you're fine. | | On _ghc.haskell.org_ I noticed you are the ``owner'' of _type | inference and interface files._ | | A year ago I started a project that requires integer type-level | literals but I soon had to drop it because GHC wasn't able to | simplify simple type equalities. As a consequence, I had to | add lots and lots of constraints to make my code work, which | effectively meant the code became unmaintainable because a small | change requlted in lots of errors. | | I know have a bit more time to work on the project and I'd like | to see if it's possible to ``talk'' to somebody in the GHC team | to see if we can improve type-level literal inference for natural | numbers. | | Is there somebody who's ``responsible'' for this area in the GHC | team? If yes, would you mind giving me their contact details? | | Regards, | | | Marc van Dongen

2 1

GHC Weekly News - 2015/02/23
by Austin Seipp 23 Feb '15

23 Feb '15

(This post is available online at https://ghc.haskell.org/trac/ghc/blog/edit/weekly20150223) Hi *, It's once again time for your sometimes-slightly-irregularly-scheduled GHC news! This past Friday marked the end of the FTP vote for GHC 7.10, there's an RC on the way (see below), we've closed out a good set of patches and tickets from users and pushed them into `HEAD`, and to top it off - it's your editor's birthday today, so that's nice! Quick note: as said above GHC HQ is expecting to make a '''third''' release candidate for GHC 7.10.1 soon in early March since the delay has allowed us to pick up some more changes and bugfixes. We plan on the final release being close to the end of March (previously end of February). This week, GHC HQ met up again to discuss and write down our current priorities and thoughts: - After discussing our current timetable - as we're currently hovering around the ICFP deadline - we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. This was the main take away from our meeting today. We've also had a little more list activity this week than we did before: - The FTP debate has ended, and the results are in: GHC 7.10.1 will continue with the generalized Prelude, known as "Plan FTP". https://mail.haskell.org/pipermail/libraries/2015-February/025009.html - Edward Kmett announced the `directory` package needed an active maintainer to step up - and luckily, Phil Ruffwind and Elliot Robinson did just that and stepped up as maintainers! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008358.html - Kazu Yamamoto asked about a behavioral change in `ghc-7.10` for `Data.Char` - it turns out this difference looks like it's caused by GHC 7.10 shipping an update to use Unicode 7.0 datasets. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008371.html - Thomas Bereknyei asked about a fundamental change in the Arrow desugarer, and whether or not something like this was worth it. Jan Stolarek and Ross Paterson stepped in to speak up to some specifics Thomas had about. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008377.html - Gabor Grief spoke up about strange behavior in the desugarer when using `RebindableSyntax` and `RankNTypes`, which Adam Gundry popped in to say may be a deeper issue due to the way typechecking and desugaring interact - https://mail.haskell.org/pipermail/ghc-devs/2015-February/008383.html - Johan Tibell announced Cabal 1.22.1.0, which will ship with GHC 7.10. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008388.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit 1b82619bc2ff36341d916c56b0cd67a378a9c222 - The `hpc` commands now take a configurable verbosity level (merged to `ghc-7.10) - Commit 0fa20726b0587530712677e50a56c2b03ba43095 - GHC now errors out on a module explicitly declared `Main` without a `main` export. Closed tickets the past week include: #9266, #10095, #9959, #10086, #9094, #9606, #9402, #10093, #9054, #10102, #4366, #7604, #9103, #10104, #7765, #7103, #10051, #7056, #9907, #10078, #10096, #10072, #10043, #9926, #10088, #10091, #8309, #9049, #9895, and #8539. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0