August 2013 - ghc-devs

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

extending GHC plugins with Hooks
by Luite Stegeman 11 Sep '13

11 Sep '13

hi all, Sorry for taking so long to get back with this. I'm proposing a somewhat general way for adding 'hooks' to the GHC API, where users can override parts of the default compiling pipeline. Hooks are simply functions or actions that replace existing compiler functionality. This means that usually only one application can use a specific hook at a time. The obvious data structure to store the hooks is DynFlags. Unfortunately defining hooks in DynFlags directly would give birth to the mother of all import cycles, and it would also break the split-dll scheme on Windows. So here's the idea: - Define each hook in the module where it's exported - For each hook make a 'phantom' DataType and an instance for the Hook type familiy - Add a TypeRep based map in DynFlags [0] - For each hooked function, check for existence of a hook in DynFlags, otherwise run the default. Example: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… Now this approach does have some disadvantages: - No clear integration with existing plugins (I've tried adding an onLoadPlugin field to Plugin, where the Plugin could update DynFlags when it's loaded, but it was a bit messy, and plugins would not be loaded in time for some hooks, particularly what Edsko needs) - More of GHC depends on type families - Decentralized hooks definitions feel a bit messy So I'm open to suggestions for improvements (or replacements) of this scheme. I have some time the coming weeks to clean up or change the patch. We've been testing some hooks with GHCJS for a while, and so far they seem to provide what we need (but I'm going to doublecheck the coming weeks that we don't have missing functionality): - Customizations for linking JavaScript code with our own library locations [1] - Hooking into the DriverPipeline so we can use the compilation manager [2] - Desugaring customizations to remove some C-isms from the FFI code [3] - Typechecking foreign import javascript imports [4] - Override the built-in GHC.Prim so we can customize primop types [5] I think it's easy to add those for Edsko and Thomas as well. luite [0] https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [1] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44 [2] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [4] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [5] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… (sorry the linked patch also contains other modifications required for GHCJS, that i'm going to submit separately)

6 9

More windows woe
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

OK, so now my windows build is getting further, but it now falls over here. This one looks more straightforward! Can anyone help? Simon "inplace/bin/ghc-stage1.exe" -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-fno-omit-frame-pointer -optc-g -optc-O0 -optc-DRtsWay=\"rts_debug\" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/CheckUnload.c -o rts/dist/build/CheckUnload.debug_o cc1.exe: warnings being treated as errors rts\CheckUnload.c: In function 'checkUnload': rts\CheckUnload.c:257:7: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:293:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' rts\CheckUnload.c:297:11: error: format '%s' expects type 'char *', but argument 2 has type 'pathchar *' bash-3.1$

3 9

cvs-ghc archives
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

Links like this one fail to work. Is this permanent? Thanks! http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

4 3

Anyone else failing to validate on 'linker_unload'?
by Ryan Newton 04 Sep '13

04 Sep '13

That test builds an executable named 'linker_unload' which segfaults for me. Valgrind says this: ==42800== Invalid read of size 8 ==42800== at 0x66945F: checkUnload (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x657F7A: GarbageCollect (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x651790: scheduleDoGC (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x6518B4: performGC_ (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x403BB1: main (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== Address 0x5bfdd20 is 80 bytes inside a block of size 120 free'd ==42800== at 0x4C273F0: free (vg_replace_malloc.c:446) ==42800== by 0x66945E: checkUnload (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x657F7A: GarbageCollect (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x651790: scheduleDoGC (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x6518B4: performGC_ (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) ==42800== by 0x403BB1: main (in /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) This went the same across a couple different independent checkouts. -Ryan

4 10

Building on Windows with msys
by Simon Peyton-Jones 04 Sep '13

04 Sep '13

Friends My Windows build (new laptop) got stuck again, but this time I managed to work out what is going on. This email is just to record the issue; I'll add something to the wiki. tl;dr: a MSYS build will fail in a deeply strange way if your MSYS bin directory doesn't take priority over the windows/system32 director. Symptom: "sh libtool" hangs indefinitely. The process manager shows an extant "cmd" and "sed", but nothing else. libtool is a shell script that comes from a tarball, and is unpacked into libraries/integer-gmp/gmp/gmpbuild/libtool Cause: libtool invokes the following command line (in the function func_convert_coer_msys_to_w32: cmd /c "echo blah" and pipes the result to sed. But MSYS mangles the command line to turn slashes into backslashes. So the actual command line is more like cmd \c "echo blah" which does something entirely different, and indeed hangs waiting for input on stdin. Solution: So how did this ever work on any MSYS installation? Because * msys/1.0/bin has a little script "cmd" which hands off to the real c:/windows/system32/cmd * MSYS does not mangle the command-line for programs in msys/1.0/bin * On my old laptop, msys/1.0/bin was in my path before c:/windows/system32. So plain "cmd" gets the script, and MSYS does not mangle the command line. The script passes arguments on unchanged to the real cmd. * NB: c:/windows/system32 is in the "system" path, which precedes the "user" path. So no amount of fiddling with the "user" path will fix this. There are two solutions: o Modify the system path o Use a .bashrc file to prepend the stuff you need This is pretty subtle stuff. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 1

New official language extension tokens for GHC 7.8.1
by Herbert Valerio Riedel 04 Sep '13

04 Sep '13

Hello GHC Devs, Which of the language extensions listed in `expectedGhcOnlyExtensions` in http://ghc.haskell.org/trac/ghc/browser/testsuite/tests/driver/T4437.hs#L33 are deemed ready for public consumption in GHC 7.8.1, and can be registered with upstream Cabal now (maybe even for the upcoming 1.18.0 release)? Related: http://ghc.haskell.org/trac/ghc/ticket/8176 Cheers, hvr

3 4

RE: [Haskell-cafe] Announcing GHC iOS
by Simon Peyton-Jones 02 Sep '13

02 Sep '13

Great. Please thank Stephen too.. I don't have his email. Just go ahead and modify http://ghc.haskell.org/trac/ghc/wiki/CodeOwners http://ghc.haskell.org/trac/ghc/wiki/Platforms I assume iOS will become a tier-2 platform? Simon From: Luke Iannini [mailto:lukexipd@gmail.com] Sent: 30 August 2013 09:07 To: Simon Peyton-Jones Cc: Austin Seipp Subject: Re: [Haskell-cafe] Announcing GHC iOS Certainly! And I'd be happy to take on maintainership of GHC iOS if that's what you mean - I've committed to a very large project using it so I'll be maintaining it anyway : ). I'd guess Stephen would feel the same. And thanks so much for the kind words, it means the world! Thank you infinitely for Haskell : ). Cheers Luke On Fri, Aug 30, 2013 at 12:32 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Should we update the "Platform maintainers" on http://ghc.haskell.org/trac/ghc/wiki/TeamGHC or the list of supported platforms on http://ghc.haskell.org/trac/ghc/wiki/Platforms? From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org<mailto:haskell-cafe-bounces@haskell.org>] On Behalf Of Luke Iannini Sent: 29 August 2013 21:56 To: Haskell Cafe Subject: Re: [Haskell-cafe] Announcing GHC iOS Stephen provided some more credits - thanks so much to all! Three connected projects concerning cross-compilation: *Registerised ARM support, added using David Terei's LLVM compiler back end with Stephen Blackheath doing an initial ARMv5 version and LLVM patch and Karel Gardas working on floating point support, ARMv7 compatibility and LLVM headaches. Ben Gamari did work on the runtime linker for ARM. *General cross-compiling, with much work by Stephen Blackheath and Gabor Greif (though many others have worked on this). *A cross-compiler for Apple iOS. iOS-specific parts were mostly Stephen Blackheath with Luke Iannini on the Cabal patch, testing and supporting infrastructure, also with assistance and testing by Miëtek Bak and Jonathan Fischoff, and thanks to many others for testing; The iOS cross compiler was started back in 2009 by Stephen Blackheath with funding from Ryan Trinkle of iPwn Studios. Thanks to Ian Lynagh for making it easy for us with integration, makefile refactoring and patience, and to David Terei for LLVM assistance. On Thu, Aug 29, 2013 at 1:43 PM, Luke Iannini <lukexipd(a)gmail.com<mailto:lukexipd@gmail.com>> wrote: Hi all! (in case you don't read /r/haskell : )) Stephen Blackheath and I are extremely happy to report that as of today, GHC can natively build binaries for iOS devices and the iOS Simulator. You'll find everything you need here: http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS The short of it is you can use "ghc-ios myFiles.hs" to get a universal ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project. Stephen's already working on some wonderful FRP-powered games, I'm working on a project called SpaceTime that I'll announce shortly, and you may now all begin creating insanely great iOS software using the finest language in the world : ). Stephen deserves the lion's share of the credit for this project - it's been over 3 years in the making! Many thanks to Maxwell Swadling for generalizing static library builds into a -staticlib flag for GHC, Carter Schonwald for compilation guidance, and the venerable Austin Seipp for reviewing and merging our patches.

4 11

Nightlies not working?
by Edward Z. Yang 02 Sep '13

02 Sep '13

The last nightly I see is from the 22nd; did they get turned off? Edward

3 2

Current state of ghc boot lib versions vs. hackage
by Herbert Valerio Riedel 01 Sep '13

01 Sep '13

I've compared what versions current GHC HEAD uses w/ vs. what's currently available on Hackage (see below); So currently, the following packages have newer versions available on hackage than are used in GHC HEAD: - binary - containers - primitive - time - vector In order to clarify a point that has been an issue in the past: Can it be assumed that the GHC 7.8 feature-freeze scheduled for 14 Sept 2013[1] is also the library version freeze deadline, by which upstream package authors shall submit new package versions they want to ship as GHC boot libs w/ GHC 7.8.1? (and thus should be given an "heads-up" asap) ------------------------------------------------------------ package hackage GHC HEAD ------------------------------------------------------------ Cabal 1.18.0 == 1.18.0 array 0.4.0.1 < 0.4.0.2 base 4.6.0.1 < 4.7.0.0 bin-package-db 0.0.0.0 == 0.0.0.0 binary 0.7.1.0 > 0.7.0.0 bytestring 0.10.2.0 < 0.10.3.0 containers 0.5.2.1 > 0.5.0.0 deepseq 1.3.0.1 < 1.3.0.2 directory 1.2.0.1 == 1.2.0.1 dph-base 0.7.0.1 < 0.8.0.1 (dph-lifted-base) 0.7.0.1 < 0.8.0.1 (dph-lifted-boxed) - 0.8.0.1 (dph-lifted-copy) 0.7.0.1 < 0.8.0.1 (dph-lifted-vseg) 0.7.0.1 < 0.8.0.1 (dph-prim-interface) 0.7.0.1 < 0.8.0.1 (dph-prim-par) 0.7.0.1 < 0.8.0.1 (dph-prim-seq) 0.7.0.1 < 0.8.0.1 filepath 1.3.0.1 < 1.3.0.2 (ghc) 7.6.3 < 7.7.20130826 ghc-prim 0.3.0.0 < 0.3.1.0 haskeline 0.7.0.3 < 0.7.0.4 (haskell2010) 1.1.1.0 == 1.1.1.0 (haskell98) 2.0.0.2 < 2.0.0.3 hoopl 3.9.0.0 < 3.10.0.0 hpc 0.6.0.0 < 0.6.0.1 integer-gmp 0.5.0.0 < 0.5.1.0 old-locale 1.0.0.5 == 1.0.0.5 old-time 1.1.0.1 == 1.1.0.1 pretty 1.1.1.0 == 1.1.1.0 primitive 0.5.0.1 > 0.4.0.1 process 1.1.0.2 < 1.2.0.0 random 1.0.1.1 == 1.0.1.1 rts 1.0 == 1.0 template-haskell 2.8.0.0 < 2.9.0.0 terminfo 0.3.2.5 == 0.3.2.5 time 1.4.1 > 1.4.0.2 transformers 0.3.0.0 == 0.3.0.0 unix 2.6.0.1 < 2.7.0.0 vector 0.10.0.1 > 0.9.1 xhtml 3000.2.1 == 3000.2.1 ------------------------------------------------------------ Cheers, hvr [1]: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8

5 4