March 2016 - ghc-devs

Syntax changes due to TypeInType
by Matthew Pickering 15 Mar '16

15 Mar '16

Hello, I'm trying to update the haskell-src-exts parser for the syntax changes in GHC 8 but I'm struggling to find information about what exactly the kind equalities patch has changed. Could someone please give me a brief overview about what changes were made to the parser? I was waiting for the manual entry (D1995) but whilst it is illuminating about the semantic changes, the syntactic changes are a bit less clear to me. A very high-level overview would be helpful so I can then look at the diff to find the finer details. Matt

2 1

RE: Semantics of IORefs in GHC
by Simon Peyton Jones 14 Mar '16

14 Mar '16

Maclan I’m glad you enjoyed the awkward squad paper. I urge you to write to the Haskell Café mailing list and/or ghc-devs. Lots of smart people there. Ryan Newton is working on this kind of stuff; I’ve cc’d him. But my rough answer would be: IORefs are really only meant for single-threaded work. Use STM for concurrent communication. That’s not to say that we are done! The Haskell community doesn’t have many people like you, who care about the detail of the memory model. So please do help us :). For example, perhaps we could guarantee a simple sequential memory model without much additional cost? Simon From: Madan Musuvathi Sent: 11 March 2016 19:35 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Semantics of IORefs in GHC Dear Simon, I really enjoyed reading your awkward squad paper<http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/…>. Thank you for writing such an accessible paper. My current understanding is that the implementation of IORefs in GHC breaks the simple semantics you develop in this paper. In particular, by not inserting sufficient fences around reads and writes of IORefs, a Haskell program is exposed to the weak-memory-consistency effects of the underlying hardware and possibly the backend C compiler. As a result, the monadic bind operator no longer has the simple semantics of sequential composition. Is my understanding correct? This is very troublesome as this weaker semantics can lead to unforeseen consequences even in pure functional parts of a program. For example, when a reference to an object is passed through an IORef to another thread, the latter thread is not guaranteed to see the updates of the first thread. So, it is quite possible for some (pure functional) code to be processing objects with broken invariants or partially-constructed objects. In the extreme, this could lead to type-unsafety unless the GHC compiler is taking careful precautions to avoid this. (Many of these problems are unlikely to show up on x86 machines, but will be common on ARM.) I am sure the GHC community is addressing these problems one way or the other. But, my question is WHY? Why can’t GHC tighten the semantics of IORefs so that the bind operation simply means sequential composition? Given that Haskell has a clean separation between pure functional parts and “awkward” parts of the program, the overheads of these fenced IORefs should be acceptable. My coauthors and I wrote a recent SNAPL article<http://research.microsoft.com/apps/pubs/default.aspx?id=252150> about this problem for other (“less-beautiful” :)) imperative languages like C# and Java. I really believe we should support sequential composition in our programming languages. madan

3 2

Loading GHC into GHCi (reprise)
by Erik de Castro Lopo 14 Mar '16

14 Mar '16

Hi all, Recently Richard showed us how to load GHC into CHCi which ended up being documented here: https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler That very useful for some things, but doesn't give you access to symbols and types that have not been exported. Specifically, I'm interested in some of the inner workings of the file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to load it into GHCi using the command line: inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci -fobject-code \ -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \ -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \ -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \ -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \ -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \ -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \ -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \ -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. \ -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \ compiler/llvmGen/LlvmCodeGen.hs and it loads all the modules require, but then seems to mess up the symbol table so that it can't even find top level functions in the module it has just loaded. Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens <interactive>:1:1: error: Not in scope: ‘LlvmCodeGen.cmmDataLlvmGens’ No module named ‘LlvmCodeGen’ is imported. I even tied adding `-icompiler/llvmGen` to the above command line (from hell) before I noticed that it was already present. Anyone have any idea why this doesn't work? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 6

Fwd: Reducing boilerplate
by Sylvain Henry 14 Mar '16

14 Mar '16

Hi devs, I would like to add the support for the following automatic instance-deriving extension: module M where class G a where doG :: a -> Int class P a where doP :: a -> Int doP _ = 10 deriving instance G a where -- automatically derived instance doG = doP data X = X instance P X -- derive G X automatically print (doG X) -- print 10 See the forwarded mail below for the real context. This extension has been proposed by someone before as InstanceTemplates: https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates I have modified the parser and the renamer accordingly to get: class M.G a_awb where M.doG :: a_awb -> Int class M.P a_ap6 where M.doP :: a_ap6 -> Int M.doP _ = 10 instance M.G a_ap6 where M.doG = M.doP I am new to the compiler part of GHC, so I have a few questions before I continue: 1a) does it make sense to store the renamed class instance declaration in an interface file? (supposing it only uses exported methods/types; we could check that) 1b) will it be possible to create a new instance declaration in another module by just doing the substitution [a_ap6 -> X] in it? (i.e. when we parse "instance P X", do we know that it means [a_ap6 -> X] in class P (and not [a -> X])?) 2) maybe I should go a different way and store only the derived instance methods as we store class default methods? Any insight appreciated! Thanks, Sylvain ---------- Forwarded message ---------- From: Sylvain Henry <hsyl20(a)gmail.com> Date: 2016-03-05 14:56 GMT+01:00 Subject: Reducing boilerplate To: Haskell Cafe <haskell-cafe(a)haskell.org> Hi, To write FFI bindings, I use c-storable-deriving [1] to automatically derive CStorable instances for many data types (the only difference between Storable and CStorable is that CStorable provides default methods for types that have Generic instances): {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveAnyClass #-} ... data X = X { fieldStatus :: Vector 24 Word8 , fieldPadding :: Word8 } deriving (Generic, CStorable) However I also need a Storable instance, hence I have to write (the "c*" methods are provided by CStorable): instance Storable X where peek = cPeek poke = cPoke alignment = cAlignment sizeOf = cSizeOf Is there a way to automatically generate this instance for every data that has an instance of CStorable? Ideally, I would like to say once and for all: instance CStorable a => Storable a where peek = cPeek poke = cPoke alignment = cAlignment sizeOf = cSizeOf As I don't think it is currently possible, would it be sensible to add the support for automatically derived instances attached to classes (as a GHC extension)? Regards, Sylvain [1] https://hackage.haskell.org/package/c-storable-deriving

3 4

Disappearing case alternative?
by Conal Elliott 12 Mar '16

12 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 09 Mar '16

09 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