- ghc-devs - Haskell.org

Disappearing case alternative?
by Conal Elliott 13 Mar '16

13 Mar '16

I'm working on a GHC plugin, mainly in the form of a "builtin" rewrite rule, and I'm seeing a strange disappearance of a case alternative. With -ddump-rule-rewrites, I can see before & after the disappearance: Here's one rule firing with the alternative present: Rule fired Rule: reify Before: reifyP TyArg Pair Int -> Int ValArg \ (ds :: Pair Int) -> case ds of _ { :# a b -> $fNumInt_$c+ a b } After: lamP @ (Pair Int) @ Int "ds"# (\ (ds :: EP (Pair Int)) -> reifyP @ Int (case evalP @ (Pair Int) ds of _ { :# a b -> $fNumInt_$c+ a b })) Cont: StrictArg toE Stop[BoringCtxt] E Prim (Pair Int -> Int) The next thing I see is the rule firing again on the residual reifyP application, but with the case alternative gone: Rule fired Rule: reify Before: reifyP TyArg Int ValArg case evalP @ (Pair Int) ds of wild { } After: ... Any ideas what's causing the disappearance? Thanks. - Conal

2 2

A performance predicament
by Richard Eisenberg 11 Mar '16

11 Mar '16

Hi devs, I'm working on some compiler performance bugs. I've implemented caching for coercion kinds at Phab:D1992. But tests show a net slowdown, which I'm currently investigating. I could abandon this work for 8.0, but it really should show an improvement, and so I'm looking deeper. A little profiling has shown that the (>>=) operator of the FlatM monad is doing 13% of all allocations on a test program (T3064). The sad thing is that, if I understand correctly, this bind shouldn't do any allocation at all! Here are the relevant definitions: > newtype FlatM a = FlatM { runFlatM :: FlattenEnv -> TcS a } > newtype TcS a = TcS { unTcS :: TcSEnv -> TcM a } > type TcM = TcRn > type TcRn = TcRnIf TcGblEnv TcLclEnv > type TcRnIf a b = IOEnv (Env a b) > newtype IOEnv env a = IOEnv (env -> IO a) As we can see here, FlatM a is equivalent to (Foo -> Bar -> Baz -> IO a). So working in this monad should just pass around the three parameters without doing any allocation, unless IO's bind operation does allocation. (I assume we use magic to prevent that last piece.) I've tried adding INLINE to the various pieces to no avail. Am I misunderstanding something fundamental here? I feel like I must be. Thanks, Richard PS: The allocation done by FlatM was around before my caching optimization. So I'm working slightly orthogonally to where I started. But if IOEnv is really doing something even slightly slowly, a small tweak here could net massive improvements in overall speed.

2 2

Local bindings in the static form
by Facundo Domínguez 10 Mar '16

10 Mar '16

Hello, At Tweag I/O we are considering relaxing a bit the constraints on the static form. static <exp> demands <exp> to be closed. That is, the free variables of <exp> must be bound at the top level. However, it would be fine to allow local bindings too. For instance: test :: StaticPtr ([[Int]] -> [[Int]]) test x = static (filter hasZero) where hasZero = any isZero isZero = (0 ==) Where hasZero is local but its body can be considered kind of closed (all free variables refer to top-level bindings or other *closed* local bindings.). We would need for this implementation a way to test closedness in this sense. Could there be any similar test implemented already in GHC? Thanks, Facundo [1] https://ghc.haskell.org/trac/ghc/ticket/11656

2 3

Change in GHC release timing policy
by Ben Gamari 10 Mar '16

10 Mar '16

tl;dr. We'll be introducing a week-long gap between the tagging of the source release and the release announcement to allow providers of binary distributions to get their builds together. Hello everyone! While Austin and I try to produce binary distributions for as many of the major platforms as we can, we are of course unable to support everything. Thankfully, we are lucky to have a number of reliable contributors who consistently provide builds for those platform that we can't handle ourselves. These include, Karel Gardas, who provides Solaris, OpenBSD, and Linux builds for a variety of platforms Páli Gábor János, who provides FreeBSD builds Jens Petersen, who ensures that GHC is well-represented on Redhat distributions Gershom, Jason Dagit, who handle build of the Haskell Platform on many platforms Randy Polen, who handles building of the Haskell Platform on Windows Herbert Valerio Riedel, who handles AIX builds They all deserve our thanks. However, our release process has until now not treated their efforts on an equal footing with the binary distributions produced by GHC HQ. In an attempt to fix this we're going to try changing the timing of GHC releases, * The source release will be tagged and tarballs pushed to a staging area * We will soon thereafter notify the binary distribution builders and ghc-devs@ * Everyone will go to work on their binary distributions * One week after the source release is tagged the release artifacts will be pushed to downloads.haskell.org and the release publicly announced. We hope that this will remove some of the confusion from the current process while ensuring that all platforms have the potential for support on the day of the release. We'll be trying this for 8.0.1-rc3 and the final release. If all goes well we'll continue this policy in future releases. Cheers, - Ben

2 1

Constrained Type Families?
by Evan Austin 09 Mar '16

09 Mar '16

GHC Devs, The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families: https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequ… <https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequ…> Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere? V/r, -Evan

5 11

necessary to build for all platforms?
by Richard Eisenberg 09 Mar '16

09 Mar '16

Hi devs, Watching the files being compiled slowly scrolling by, as I too often do, led me to this question: Is there a reason that my machine (an x86-based Mac) is building modules in the SPARC or PPC directory? These absolutely need to be compiled when validating on any machine, but if I'm on the devel2 build settings, I don't see the need. Am I right that these aren't needed for debugging? If I am, is it reasonable to try to teach the build scripts how to avoid doing this? Thanks! Richard

3 2

"token is not a valid binary operator in a preprocessor subexpression" in GHC HEAD build
by Conal Elliott 08 Mar '16

08 Mar '16

I'm trying to build GHC HEAD on Mac OS after a fresh git-pull, and I'm getting the following: libraries/binary/src/Data/Binary/Put.hs:38:27: error: token is not a valid binary operator in a preprocessor subexpression #if MIN_VERSION_bytestring(0,10,4) Any insights/suggestions? I don't need the very latest HEAD version; just a version with ticket 11651 fixed (https://ghc.haskell.org/trac/ghc/ticket/11651#comment:3) and even for that item, I don't mind patching the source myself. Thanks! - Conal

1 1

Specialized type hints
by Christopher Allen 07 Mar '16

07 Mar '16

I'd like to see how warm people would be to catching GHC's type error quality up a bit. I did a write-up on a confusion a reader of our book had: https://gist.github.com/bitemyapp/c27c721b92dab0248433 This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance. I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded? By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires. I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code. -- Chris Allen

5 7

Fwd: [GHC] #11683: compiled files don't load in ghci
by George Colpitts 06 Mar '16

06 Mar '16

---------- Forwarded message --------- From: GHC <ghc-devs(a)haskell.org> Date: Sun, Mar 6, 2016 at 1:23 PM Subject: [GHC] #11683: compiled files don't load in ghci To: Cc: <ghc-tickets(a)haskell.org> #11683: compiled files don't load in ghci -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- compiled files don't load in ghci {{{ ghc -DYNAMIC bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :show modules Main ( bug.hs, interpreted ) *Main> }}} According to the doc, file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html #loading-compiled-code, this should work: {{{ Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code (if you are on a platform that supports it), and so in order to use compiled code with GHCi it must be compiled for dynamic linking. }}} Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the same thing: {{{ if you say :load Foo in GHCi Foo was compiled with -dynamic: loads Foo.o }}} Interestingly -fobject-code does work: {{{ ghci -ignore-dot-ghci -fobject-code GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> :load bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Ok, modules loaded: Main. Prelude Main> }}} Unfortunately when I do {{{ ghci -v -ignore-dot-ghci -fobject-code }}} I don't see why it works. It doesn't seem to use just ghc to compile , it also uses gcc, see attached file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

'lub' and 'both' on strictness - what does it mean for products to have different arity?
by Ömer Sinan Ağacan 04 Mar '16

04 Mar '16

I was looking at implementations of LUB and AND on demand signatures and I found this interesting case: lubStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith lubArgStr s1 s2) | otherwise = HeadStr The "otherwise" case is interesting, I'd expect that to be an error. I'm trying to come up with an example, let's say I have a case expression: case x of P1 -> RHS1 P2 -> RHS2 and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to me like a type error leaked into the demand analysis. Same thing applies to `bothDmd` too. Funnily, it has this extra comment on this same code: bothStr (SProd s1) (SProd s2) | length s1 == length s2 = mkSProd (zipWith bothArgStr s1 s2) | otherwise = HyperStr -- Weird Does "Weird" here means "type error and/or bug" ? Should I try replacing these cases with panics and try to validate?

3 7