- ghc-devs - Haskell.org

Aliasing current module qualifier
by Herbert Valerio Riedel 29 Sep '14

29 Sep '14

Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr

5 5

Re: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa)
by Joachim Breitner 29 Sep '14

29 Sep '14

Hi, Am Samstag, den 27.09.2014, 21:07 +0000 schrieb git(a)git.haskell.org: > commit f636faa7b2b7fc1d0663f994ad08f365d39a746d > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Sat Sep 27 22:55:19 2014 +0200 > > Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` > > This is made possible by the AMP, as we don't need the `WrappedMonad` > helper for that anymore. according to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=f636faa7b2b7fc1d0663f994ad… this has caused a 11% regression in fibheaps allocation: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/allocs/fibheaps&env… 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: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a)
by Joachim Breitner 29 Sep '14

29 Sep '14

Hi, Am Sonntag, den 28.09.2014, 13:07 +0000 schrieb git(a)git.haskell.org: > commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Sun Sep 28 13:02:53 2014 +0200 > > Extend `Foldable` class with `length` and `null` methods > > This completes the `Foldable` class by two important operations which > this way can be optimised for the underlying structure more easily. > > A minor fix for the `containers` submodule was needed to due name clash > > Addresses #9621 > > Reviewed By: ekmett, dfeuer, austin > > Differential Revision: https://phabricator.haskell.org/D250 this broke nofib: ==nofib== para: time to compile Main follows... /data1/ghc-builder/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -c Main.lhs -o Main.o Main.lhs:517:32: No instance for (Foldable t0) arising from a use of ‘step’ The type variable ‘t0’ is ambiguous Relevant bindings include par1' :: [t0 a] -> [[t0 a]] (bound at Main.lhs:516:2) Note: there are several potential instances: instance Foldable ((,) a) -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ instance Foldable (Either a) -- Defined in ‘Data.Foldable’ ...plus three others In the first argument of ‘fold1’, namely ‘step’ In the second argument of ‘(.)’, namely ‘fold1 step start’ In the second argument of ‘(.)’, namely ‘minWith cost . fold1 step start’ <<ghc: 93451064 bytes, 44 GCs, 4435640/8217616 avg/max bytes residency (4 samples), 31M in use, 0.001 INIT (0.001 elapsed), 0.051 MUT (0.056 elapsed), 0.057 GC (0.057 elapsed) :ghc>> 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

tar --help is failing on Solaris.
by Karel Gardas 27 Sep '14

27 Sep '14

Hello Mikhail, you are the author of the patch eaf2aae18603965ff668384b391fcaa14de19823 in libraries/Cabal which you have merged into GHC HEAD on September 25 in the patch 4be50969491aa471d6c9ab3b9339036a355d45c6 The problem is that your patch breaks build on Solaris, here is the log from the Solaris/x86 builder: http://haskell.inf.elte.hu/builders/solaris-x86-head/178/10.html Could you be so kind and revert this patch or fix it to also work on Solaris? For Solaris the change should be easy, simply if you invoke Solaris' tar with --help, it'll fail with exit code 1 and help message printed into the stderr. If you are curious if it supports --format, then no. Please let me know if you are able to push fix or revert during next week or if I shall deal with it myself. I can't just fix that now myself since I'm overloaded with other tasks till Wednesday night... Thanks! Karel

3 3

HEADS UP: Running cabal install with the latest GHC
by Edward Z. Yang 27 Sep '14

27 Sep '14

Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in HEAD. So, how do you get a version of cabal-install (and Cabal) which is new enough to do what you need it to? The trick is to compile Cabal using your /old/ GHC. Step-by-step, this involves cd'ing into libraries/Cabal/Cabal and running `cabal install` (or install it in a sandbox, if you like) and then cd'ing to libraries/Cabal/cabal-install and cabal install'ing that. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward

5 8

Re: Permitting trailing commas for record syntax ADT declarations
by Alexander Berntsen 26 Sep '14

26 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forwarding this & my reply to the ML as well, On 22/09/14 14:27, David Luposchainsky wrote: > +1. While you're at it, you may also want to consider allowing > leading commas for the folks that write their exports/records "the > other way round" Sure. Both styles are common in the wild, so that makes sense. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgFo4ACgkQRtClrXBQc7Xz1QEAn5rLEoUuHPGRkJIEy/ZKHuiM xxIF+i/E8X1Y5cdd5HQA/jski9JOlu7LdY1ieucpSMe2KgF3v0VHO+aO+q7QZ93x =v9Ba -----END PGP SIGNATURE-----

13 44

REMINDER: Please review the HCAR entry for GHC!
by Austin Seipp 26 Sep '14

26 Sep '14

Hi *, Just a regularly scheduled reminder: please double-check the latest HCAR entry so we can make sure it's great for the October edition: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 The current page looks good, but we're missing some things like: - Backpack updates - Information on the BBP from Herbert. - We've implemented some new optimizations since last time, like Call Arity, and some other improvements. - Other things: AArch64 support, probably other stuff. I'm sure you all remember what you did. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Linux failures
by Simon Peyton Jones 26 Sep '14

26 Sep '14

I am getting one persistent failure on Linux: =====> user001(normal) 5 of 29 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd . && ./user001 >user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) This is in libraries/unix/tests. I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 @@ -0,0 +1 @@ +ghc-stage2: ioManagerWakeup: write: Bad file descriptor I don't think these can be caused by my commits, but they should be fixed.... Any offers? Simon

4 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 26 Sep '14

26 Sep '14

I am trying to avoid having a type parameter for DynFlags, and so far the only thing that needs it is the hooks. I am currently working it through without hooks in DynFlags, and when I have something concrete I will ask againfor suggestions. I just wanted an initial test of the waters to make sure there was no a priori reason not to do it. On Fri, Sep 26, 2014 at 10:09 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.8.3 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > You'll need to be much more explicit before anyone is likely to venture an > opinion. What is the impact of "managed separately"? What is the > motivation for making a change at all? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:10> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

GHC AST Annotations
by Alan & Kim Zimmerman 26 Sep '14

26 Sep '14

Now that the landmines have hopefully been cleared from the AST via [1] I would like to propose changing the location information in the AST. Right now the locations of syntactic markers such as do/let/where/in/of in the source are discarded from the AST, although they are retained in the rich token stream. The haskell-src-exts package deals with this by means of using the SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC Located type but also has a list of SrcSpan s for the syntactic markers, depending on the particular AST fragment being annotated. In addition, the annotation type is provided as a parameter to the AST, so that it can be changed as required, see [3]. The motivation for this change is then 1. Simplify the roundtripping and modification of source by explicitly capturing the missing location information for the syntactic markers. 2. Allow the annotation to be a parameter so that it can be replaced with a different one in tools, for example HaRe would include the tokens for the AST fragment leaves. 3. Aim for some level compatibility with haskell-src-exts so that tools developed for it could be easily ported to GHC, for example exactprint [4]. I would like feedback as to whether this would be acceptable, or if the same goals should be achieved a different way. Regards Alan [1] https://phabricator.haskell.org/D157 [2] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… [3] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… [4] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-…

5 10