July 2014 - ghc-devs - Haskell.org

globalRegMaybe and ARM
by Ben Gamari 04 Aug '14

04 Aug '14

Hello Simon, b0534f7 [1] and the subsequent reversion f0fcc41d7 touched `includes/CodeGen.Platform.hs`, the former removing a panic in the case of `globalRegMaybe` being undefined for a platform and replacing it with `Nothing`. Recently I've found that my ARM builds (with -fllvm) crash at this panic whereas they did not as of the 7.8 release. Given that b0534f7 was reverted this is no doubt due to another change that I haven't identified yet. Do you have any idea what is happening here? I'm currently attempting to build with a workaround setting `globalRegMaybe _ = Nothing`, although this smells suspicously like what would happen in the unregisterized case. My other hypothesis is that MACHREGS_arm should be added to the #if MACHREGS_i386 || MACHREGS_x86_64 || MACHREGS_sparc || MACHREGS_powerpc which smells more like what a registerised architecture should do and it seems the requisite macros are defined for ARM in `stg/MachRegs.h`. Whatever happens for ARM should probably also happen for AArch64. How should `globalRegMaybe` and `freeReg` be defined for platforms that rely exclusively on the LLVM backend? Both ARM and AArch64 appear to be doing the wrong thing at present. Cheers, - Ben [1] https://github.com/ghc/ghc/commit/b0534f78a73f972e279eed4447a5687bd6a8308e#…

2 1

Overlapping and incoherent instances
by Simon Peyton Jones 02 Aug '14

02 Aug '14

Friends One of GHC's more widely-used features is overlapping (and sometimes incoherent) instances. The user-manual documentation is here<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensio…>. The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively. However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time. Using LANGUAGE OverlappingInstances simply sets the "I am an overlapping instance" flag for every instance declaration in that module. This is a Big Hammer. It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping. It brutally applies to every instance in the module. Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped. The clue might be in the command line that compiles that module! Iavor has recently implemented per-instance-declaration pragmas, so you can say instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... instance {-# OVERLAPPING #-} Show [Char] where ... This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration). This new feature will be in GHC 7.10 and I'm sure you will be happy about that. But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer. The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle. We could make that two cycles if it was helpful. However, if you want deprecation-free libraries, it will entail a wave of library updates. This email is just to warn you, and to let you yell if you think this is a bad idea. It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely - it just seems wrong not to actively push authors in the right direction. These deprecations of course popped up in the test suite, so I've been replacing them with per-instance pragmas there too. Interestingly in some cases, when looking for which instances needed the pragmas, I found...none. So OverlappingInstances was entirely unnecessary. Maybe library authors will find that too! Simon

3 3

Changing the -package dependency resolution algorithm
by Edward Z. Yang 01 Aug '14

01 Aug '14

Right now, GHC has a very complex and hard to explain algorithm for picking packages from the package database when you give it a pile of -package/-package-id/-{hide,ignore,trust,distrust}-package flags. Roughly, it currently does something like this. 1. Concatenate all of the package databases into a giant list, with system packages first and then user packages later, removing duplicate entries with the same installed package ID (preferring later packages). Call this PACKAGES. 2. Take all the -package-id flags and compute their transitive closure (call this set P). 3. Calculate the set of shadowed packages--the set of installed packages for which there exists another package with the same package ID (foo-0.1) which is in P or is later in the package stack. 4. Calculate the set of ignored packages---the set of packages which match all -ignore-package flags 5. Filter out shadowed and ignored packages from the list of packages, calling the result ALL_PACKAGES. 6. Calculate the set of broken packages---the set of packages not contained in the least fixed point of the relation that takes a set of packages, and adds all packages whose dependencies are satisfied, from ALL_PACKAGES. 7. Process the package flags in order, operating on PACKAGES (not ALL_PACKAGES). For -package/-hide-package, take the package with the *latest* version that matches the flag and are not broken (since this includes shadowed packages, the result is unique) and toggle it to be exposed/unexposed, and hide all the other packages. For -trust-package/-distrust-package, toggle the trusted bit for all instances in the database. 8. If we have exposed multiple versions of the same package name, hide all the older versions What a mouthful! I have no idea, given a set of flags, how this works. So here is an alternate proposal for an alternate way of handling these flags *when starting from an empty database* (e.g. -hide-all-packages) Suppose we maintain a set of selected packages, which starts off empty. Process each package flag in turn. For -package and -package-id, get the set of installed packages which match the flag. (If multiple package names apply, process each in turn as if it were a separate flag.) Compute the transitive closure of dependencies for all of them, and filter out all choices which have dependencies which are inconsistent with the current set of selected packages. Consistency without multi-instances is a mapping of a package name to an installed package. If there is still more than one choice, tiebreak by version, which database and time of install. (The latter tiebreak should not be necessary until we allow multiple instances of a package with the same package ID.) For -hide-package, get the set of packages which match and hide them all; for -ignore-package, hide the transitive closure of dependencies of it. For -trust,distrust-package, toggle for all matching packages as before. Here are some differences in behavior between this and the previous scheme: - It's no longer valid to indirectly depend on two different versions of the same package. Most of the time, users didn't want this anyway. Note that the current scheme prevents directly depending on two different versions by shadowing the old ones. - We can easily extend it to handle multi-instances by relaxing the consistency check. - It assumes *-hide-all-packages* at the beginning. This scheme probably works less well without that: now we need some consistent view of the database to start with. What do people think? Cheers, Edward

4 7

Multiple imports on single line
by eng. Vassil Ognyanov Keremidchiev 01 Aug '14

01 Aug '14

Hello, dear GHC developers! Is it possible to add such constructions in next GHCs: import Data.List, Data.Array, Data.Aeson, Network.HTTP.Conduit on a single line. This will simplify source code and clear the space before the actual code. Best regards, Vassil Keremidchiev

2 1

pthread.h missing
by Simon Peyton Jones 01 Aug '14

01 Aug '14

On Windows rts/T8124 is failing thus: T8124_c.c:4:21: fatal error: pthread.h: No such file or directory compilation terminated. *** unexpected failure for T8124(threaded1) Simon

2 1

Haskell Platform 2014.2.0.0 Release Candidate 3
by Mark Lentczner 01 Aug '14

01 Aug '14

Small update to the Haskell Platfrom 2014.2.0.0 release: We have new Release Candidate 3 versions of the source tarball... and a new generic-linux bindist of the platform! - source tarball: haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-srcdist…> - generic linux: haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-unknown…> *Windows and OS X users: There are no RC3 versions - as the RC2 versions seem to be holding up fine!* *General* - hptool (and hence ./platform.sh script) take a new --prefix parameter that is used for generic (non-OS X, non-Windows) builds: It sets the root under which haskell installations are located. Defaults to /usr/local/haskell. Everything will be placed in a directory named ghc-7.8.3-<arch> under this prefix. - activate-hs script for default Posix-like builds - small fixes to allow bootstrapping the platform with GHC 7.4 - README and LICENSE updated *Source Tarball* - all missing pieces now present - build platfrom from source tarball verified *Generic Linux Binary Dist* - Built from the GHC's generic Linux bindist for Deb 7 style systems - Complete tarball: this is all you need to install Haskell on a compatible system - Built on Ubuntu 12.04LTS - Tested on Ubuntu 14 - my system needed a symlink from libgmp.so to libgmp.so.10 - this seems to be an issue with the GHC bindist built components To install this: cd / sudo tar xvf ~/haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz sudo /usr/local/haskell/ghc-7.8.3-x8_64/bin/activate-hs This will finish the package registration, and install symlinks from /usr/local/bin for all the standard haskell command line tools. — Mark *shasum -a 256:* ab759ec50618f2604163eca7ad07e50c8292398a2d043fdc1012df161b2eb89a haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz 0da6879ae657481849e7ec4e5d3c4c035e090824167f97434b48af297ec17cf9 haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz

1 0

Forcing apps to collect GC stats?
by Bryan O'Sullivan 01 Aug '14

01 Aug '14

I spent a bit of time over the weekend trying to figure out how to force the RTS to collect GC statistics, but was unable to do so. I'm currently working on enriching criterion's ability to gather data, among which I'd like to see GC statistics. If I try to obtain GC stats using criterion when I'm not running the benchmark app with +RTS -T, I get an exception. Is there a way to allow criterion to forcibly enable stats collection? My efforts to do so have gotten me nowhere. It would be unfortunate if I had to tell users of criterion that they should always run with +RTS -T or add a -rtsopts clause, as they'll simply forget. And while I'm asking, why does GHC not simply collect GC stats by default? Collecting them seems to have zero cost, from what I can see? Thanks! Bryan.

5 7

RE: A couple of GHC-API questions
by Simon Peyton Jones 31 Jul '14

31 Jul '14

| This is what I mean by “resolving” the types. For single-module programs | this is trivial, we can do something like | | resolve x = do rn <- hscParseIdentifier x | hscTcRnLookupRdrName rn | | For multi-module programs it becomes trickier because we also have to | resolve the types that we’ve imported from other modules. No, that is no harder **provided those types are in scope**. So suppose you have module M where import A( Foo ) f :: Int -> Int {-# LIQUID f :: { x | ..blah..Foo..blah } -> Int #-} Here I am supposing that the Liquid Haskell specification is in a pragma of M, and mentions an imported data type Foo. To resolve the string "Foo" to the Name A.Foo (or Bar.Foo, or whatever), hscTcRnLookupRdrName will work just fine. If you import Foo qualified, then of course you'll have to use a qualified name in the source module M where import qualified A( Foo ) f :: Int -> Int {-# LIQUID f :: { x | ..blah..A.Foo..blah } -> Int #-} If you *don't* import Foo at all, then it's utterly non-obvious where to look for it, so I don't suppose you are doing that. In short, why doesn’t hscTcRnLookupRdrName do the job? Incidentally, it doesn't make sense to ask if a Name is "in scope". Only RdrNames can be "in scope" or "not in scope". Simon | example from earlier, when we type-check module B we have to turn the | String “Foo” into the Name A.Foo. This is problematic because module B | imported module A qualified, so “Foo” is not in scope inside B but | “A.Foo” is. | | I believe GHC might be avoiding this issue via the .hi files, so when you | import a Type from another module, it is already using TyCons instead of | Strings. | | > Later you say "is there a simple way to ask GHC to resolve the name x | in the context of module | > m". You could mean | > * Imagine that the unqualified name "x" appeared in module m. How do I | look it up, in m's | > top-level lexical environment. | > but I don’t think that is what you mean. | | I think this is almost exactly what I mean, except that I want to be able | to look up the unqualified “x” as well as the qualified | “SomeModuleThatMayHaveBeenRenamed.x” inside m’s top-level environment. | This is more or less what the | DynamicLoading.lookupRdrNameInModuleForPlugins function that I’ve copied | and tweaked does, but it requires the presence of the original source | code. I’m hoping there may be some other function out there that does the | same thing without requiring the source code, so we can use it for the | base libraries as well. | | > I'm confused. Could you be more concrete? | > Possibly this may help? | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType | | Thanks for the reference, I’m familiar with most of the info there | already from browsing GHC’s source, but this is laid out much more | newcomer-friendly manner :) | | Hopefully I’ve made my question a bit clearer. | | Eric

2 4

The build is broken: docs/users_guide/users_guide.xml
by Páli Gábor János 31 Jul '14

31 Jul '14

Hi there, I have dblatex installed on my builders that makes them failing for the last few days, e.g. [1]. The cause of the failure is this: "/usr/local/bin/dblatex" -P 'filename.as.url=0' docs/users_guide/users_guide.xml --ps -o docs/users_guide/users_guide.ps [..] Build users_guide.ps latex failed users_guide.tex:6509: Lonely \item--perhaps a missing list environment. users_guide.tex:6509: leading text: ...-{}\-i\-p\-i\-d} \index{-{}-{}ipid} }] Unexpected error occured The version of dblatex is 0.3.2. [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/336/10.html

1 0

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)
by Simon Marlow 31 Jul '14

31 Jul '14

4 4