June 2013 - ghc-devs - Haskell.org

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

13 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

HEAD build fails on OS X
by Andreas Voellmy 28 Aug '13

28 Aug '13

I got a fresh copy of HEAD today, and the build failed. The failing command is: $ cd libraries && sh gen_contents_index --intree haddock: internal error: /Users/andreas/repos/temp-ghc-2/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory) I have not yet had time to look into this, but hopefully someone knows what happened here. -Andi

7 17

how to checkout proper submodules
by Kazu Yamamoto 23 Aug '13

23 Aug '13

Hi, Andreas and I found that the new IO manager is not working properly in the current GHC head. I'm sure that it worked well at least on May 7. We need to narrow the range of commits, so I did: % git checkout bb2795db36b36966697c228315ae20767c4a8753 % git submodule update But this does not checkout proper submodules. For instance, libraries/base has newer commits. And of cource, building fails. Please tell us how to checkout proper submodules against a specific GHC tree. --Kazu

21 43

Patch/feature proposal: "Source plugins"
by Edsko de Vries 31 Jul '13

31 Jul '13

Sorry for the earlier mishap, here's the full email. Hi all, The plugin mechanism gives access to the program in Core; this suffices for many but not quite all purposes. Tools that need access to the original AST can call typecheckModule directly, but of course this requires using the GHC API directly. Moreover, even when using the GHC API directly anyway (as in my case), it means that tools cannot take advantage of ghc's infrastructure for dependency tracking, recompiling only changed modules, etc. Hence it would be useful to have "source plugins", which can be used both externally and when using ghc API (in the latter case I guess "hooks" would be the more appropriate terminology). Currently "core plugins" are recorded as part of DynFlags as pluginModNames :: [ModuleName], pluginModNameOpts :: [(ModuleName,String)], This makes sense when thinking of plugins only as an external mechanism, but is less convenient when using them as internal hooks, too. In my draft patch I introduce a new type "HscPlugin" (described shortly) and added sourcePlugins :: [HscPlugin], to DynFlags. HscPlugin is a record of a pair of functions; having the actual record here rather than a module name means that these functions can have a non-empty closure, which is obviously convenient when using this as a hook rather than an external plugin. In my current version HscPlugin looks like data HscPlugin = HscPlugin { runHscPlugin :: forall m. MonadIO m => DynFlags -> TcGblEnv -> m TcGblEnv , runHscQQ :: forall m. MonadIO m => Env TcGblEnv TcLclEnv -> HsQuasiQuote Name -> m (HsQuasiQuote Name) } runHscPlugin is the main function; it gets passed the TcGblEnv (which contains the type checked AST as its tcd_binds field) and gets a change to return it modified (we don't currently take advantage of that; I did that only to be in line with "core plugins"). Unfortunately, the typechecked AST is only a subset of the renamed AST (see http://www.haskell.org/pipermail/ghc-devs/2013-February/000540.html) The TcGblEnv contains a tcg_rn_decls field, which is a reference to the full renamed (as opposed to typechecked) AST, but by default this is not initialized: the typechecker only optionally retains the renamed AST, and this is hardcoded to by False. In my current patch I have changed this so that it's hard coded to be True; ideally this should become an option in DynFlags (more ideal still would be if the type checked AST would not lose any information). Unfortunately, even the renamer loses information: quasi-quotes get expanded during renaming and all evidence of that there was ever a quasi-quote there has disappeared when the renamer returns. For this reason, the HscPlugin type that I'm using at the moment also has a hook for quasi-quotes. So what I have currently done is: 1. Introduced the above HscPlugin type and added a corresponding field to DynFlags 2. Call runHscQQ in the renamer whenever a quasi-quote gets expanded. 3. Make sure that the typechecker passes the result of the renamer through. 4. Call runHscPlugin on the result of the typechecker. In my client code I then combine the information obtained from these three sources (2, 3, 4). The path of least resistance for me currently to submit this as a patch for ghc therefore be to submit a patch that does precisely what I described above, mutatis mutandis based on your feedback, except that I would add an option to add to DynFlags that would tell the type checker whether or not to pass the result of the renamer through, rather than hardcoding it. It is a little bit messy mostly because parts of the AST get lost along the way: quasi-quotes in the renamer, data type declarations and other things during type checking. A more ideal way, but also more time consuming, would be to change this so that the renamer leaves evidence of the quasi-quotes in the tree, and the type checker returns the entire tree type checked, rather than just a subset. I think that ultimately this is the better approach, at least for our purposes -- I'm not sure about other tools, but since this would be a larger change that affects larger parts of the ghc pipeline I'm not sure that I'll be able to do it. Any and all feedback on the above would be appreciated! Edsko

6 16

T3294 variies in whether it fails or not
by Simon Peyton-Jones 14 Jul '13

14 Jul '13

Ian Perf/compiler/T3294 has very different max_bytes_used when BINDIST=YES than without. See below. I don't know why. I don't know whether it matters. Maybe it's just the moment that GC strikes. But it's uncomfortable to have such an erratic test failure. Simon simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make TEST=T3294 python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2"' -e 'config.ghc_pkg="/5playpen/simonpj/HEAD-1/inplace/bin/ghc-pkg"' -e 'config.hp2ps="/5playpen/simonpj/HEAD-1/inplace/bin/hp2ps"' -e 'config.hpc="/5playpen/simonpj/HEAD-1/inplace/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-1/testsuite"' \ --only=T3294 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at Tue May 28 09:21:29 BST 2013 ====> Scanning ./all.T =====> T3294(normal) 2 of 14 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-1/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable -RTS >T3294.comp.stderr 2>&1 OVERALL SUMMARY for test run started at Tue May 28 09:21:29 BST 2013 14 total tests, which gave rise to 47 test cases, of which 46 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 0 unexpected failures simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ cat T3294.comp.stats /5playpen/simonpj/HEAD-1/inplace/lib/bin/ghc-stage2 -B/5playpen/simonpj/HEAD-1/inplace/lib -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable [("bytes allocated", "2721056936") ,("num_GCs", "540") ,("average_bytes_used", "15190408") ,("max_bytes_used", "36726792") ,("num_byte_usage_samples", "15") ,("peak_megabytes_allocated", "105") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "2.64") ,("mutator_wall_seconds", "3.25") ,("GC_cpu_seconds", "2.03") ,("GC_wall_seconds", "2.03") ] simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ make TEST=T3294 BINDIST=YES python2 ../../../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=1 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=1 -e windows=False -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../../../config/ghc -e 'config.confdir="../../../config"' -e 'config.compiler="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc"' -e 'config.ghc_pkg="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc-pkg"' -e 'config.hp2ps="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/hp2ps"' -e 'config.hpc="/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/hpc"' -e 'config.gs="gs"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../../../timeout/install-inplace/bin/timeout"' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-1/testsuite"' \ --only=T3294 \ \ \ \ \ \ Timeout is 300 Found 1 .T files... Beginning test run at Tue May 28 09:21:49 BST 2013 ====> Scanning ./all.T =====> T3294(normal) 2 of 14 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-1/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable -RTS >T3294.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 36904752 +/-15% Lower bound max_bytes_used: 31369039 Upper bound max_bytes_used: 42440465 Actual max_bytes_used: 43818472 *** unexpected failure for T3294(normal) Unexpected results from: TEST="T3294" OVERALL SUMMARY for test run started at Tue May 28 09:21:49 BST 2013 14 total tests, which gave rise to 47 test cases, of which 46 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures Unexpected failures: . T3294 [stat not good enough] (normal) simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$ cat T3294.comp.stats /5playpen/simonpj/HEAD-1/bindisttest/install dir/lib/ghc-7.7/bin/ghc -B/5playpen/simonpj/HEAD-1/bindisttest/install dir/lib/ghc-7.7 -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3294.hs +RTS -V0 -tT3294.comp.stats --machine-readable [("bytes allocated", "2724158504") ,("num_GCs", "525") ,("average_bytes_used", "16042228") ,("max_bytes_used", "43818472") ,("num_byte_usage_samples", "15") ,("peak_megabytes_allocated", "116") ,("init_cpu_seconds", "0.00") ,("init_wall_seconds", "0.00") ,("mutator_cpu_seconds", "2.77") ,("mutator_wall_seconds", "3.38") ,("GC_cpu_seconds", "2.38") ,("GC_wall_seconds", "2.38") ] simonpj@cam-05-unx:~/5builds/HEAD-1/testsuite/tests/perf/compiler$

2 1

[PATCH] Haddockify some comments in compiler/hsSyn/HsBinds.lhs
by Mateusz Kowalczyk 13 Jul '13

13 Jul '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have turned some comments in compiler/hsSyn/HsBinds.lhs into Haddock format. They were just sitting there, hidden from the world (to spite anyone scratching their heads when looking through the generated docs, like myself). They were already written so why not use them? See attachment. I trust that they're right but I cannot guarantee it. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRsQ3TAAoJEM1mucMq2pqX9lQP/Al86/rfrr+Q6yLf8HtudIeT +vBDu/r4wClZmNzKKxrtgECELl5UoRX33EUdY2ydHAh0VyPFQZwK1G2Xzktg6zjS 8DSvPhHWDvlces3EWdQOyScwMG+jm+/ezdhU7LVQjCEPvfSQ21csIrDkdRgGH918 qD6wThZ7lZMfccJkkFxya8MIN9XJxQCW65XGUobVgpY5OyQTmy5Dj5teYz+GW/7O VWUUDyNQP6OtlmefhdvHEjrq88Gl+YylAa6x4B27mavRxmdV2gzMxcApfcwj5vkD 1T8+Azl8zpAOwOLa02is7yb0gsuIo/naropcicSeyz67S+Bivp/XO/Z66n6BEAhW iIr+fCTJeArU2NZ5erT/Awkcw9yam8hD3/3wJgaME07Q6Qmfd0l1NoXm4u/6M/Hr yLFhinnRBe/NiENf9wxWzSCky/lkvZjmWcchxPYFN1ZtmOKnP07S1YnjKZ+XEwwW X72XIMAbKzUkhm615UkV//Z09ueTEXpHvA7JRiCVpCivpHX8mXWwe5Su5tlrvL6t /DO2uUawD9OcPpSgarqI1/j+JmWmDq0/ayGI2Wj5PQmp5gFZS8EfYANYXDOCa4nx bZh32ZIgh+agoMvo/XqhRdO0oj/rTd9V3mrh3Na1Yu0KcC3uRwkiBfj0S0C/Wb92 bjxukm7b56XtazyUk2BX =0okt -----END PGP SIGNATURE-----

2 2

package installation woes with Template Haskell / dynamic libraries
by Richard Eisenberg 13 Jul '13

13 Jul '13

Hi all, --- tl;dr: cabal fails to install a package where one module in the package uses another module via Template Haskell, requiring a .dyn_o file. The compilation order, though, makes .o files before .dyn_o files, so installation fails. Is this my fault or cabal's? --- I've built and installed HEAD (as of Apr 8), on Mac OS 10.8.2, without specifying a build.mk file (i.e., using the defaults). I then tried to install the singletons package. This package has multiple modules, one of which uses another in some Template Haskell code. The TH code also uses the syb and mtl packages. - A simple `cabal install singletons` fails when compiling the module that uses TH, because there are no .dylib files for the syb or mtl libraries. I add 'shared: True' to my ~/.cabal/config file, "dangerous"ly reinstall mtl and syb and try again. - Now, `cabal install singletons` still fails during compilation, because the TH code looks for Singletons.dyn_o, which doesn't exist. The problem is that the vanilla build happens before the shared build, and TH seems to require the shared build. - I try `cabal install singletons --disable-library-vanilla`, and everything compiles, but then I get this: Installing library in /Users/rae/Library/Haskell/ghc-7.7.20130407/lib/singletons-0.8.5/lib cabal: dist/build/HSsingletons-0.8.5.o: does not exist - In the hopes that cabal kept the .dyn_o files around, I try regular `cabal install singletons`, but cabal seems to have discarded the .dyn_o files and I get the same error as before. - So, I `cabal unpack singletons`, go into the singletons folder, and run `cabal install --disable-library-vanilla`, and get the installation error as before. But, the compile worked and the .dyn_o files are kept! So, a final `cabal install` now works. Phew. I have a relatively weak understanding of cabal. My question is: Is the problem I've run into here based on local settings that need to be fixed? Is there a moving part somewhere that needs to be upgraded? Or, is this a real bug somewhere? If the problem isn't local, I see three separate bugs here: 1) I had to "dangerous"ly reinstall mtl and syb to get the shared libraries after updating my ~/.cabal/config. I think it should be possible to augment an existing package installation with a new "way" without reinstalling. 2) If a package uses TH and depends on another package, and if TH requires dynamic linking, cabal should automatically install dynamic versions of the library, overriding settings in ~/.cabal/config. Or, if overriding settings is a no-no, it should give a stern warning. It would make sense if this dependency were required to be stated in the package's .cabal file. 3) If a package uses TH and depends on itself, similar logic should apply (requiring a dynamic build), and the order of compilation should be fixed. I can understand (but, without more knowledge, would disagree with) an argument discarding 1) and 2) as natural consequences of a silly user, but 3) -- especially the compilation order -- seems more fundamental. I don't know of a way of installing singletons now without unpacking it and dancing around this problem. What do you think? Are these bugs? Am I a silly user? Or both? Thanks! Richard

2 1

status of template haskell + cross compiling plans for 7.8?
by Carter Schonwald 04 Jul '13

04 Jul '13

Hey All, Whats the story planned for template haskell + cross compiler support come ghc 7.8? I understand theres a lot of Template Haskell design underway, some of which will help support tools like Manuel's Inline-Objective-C work. Does this mean that factored out within this reorganization is a better story for cross compilation? Especially since one kill "app" for the Inline-Objective-C template haskell work would be writing IOS applications. Though I guess that also touches on the need to sort out supporting "FAT" ARM binaries too, right? This intersects with a few different large subsets of tickets, so i'm not sure if any single ticket is the right fora for this question. thanks! -Carter

9 13

PSA: GHC can now be built with Clang
by Austin Seipp 03 Jul '13

03 Jul '13

Hi all, As of commit 5dc74f it should now be possible to build a working stage1 and stage2 compiler with (an extremely recent) Clang. With some caveats. You can just do: $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang $ make I have done this work on Linux. I don't expect much difficulty on Mac OS X, but it needs testing. Ditto with Windows, although Clang/mingw is considered experimental. The current caveats are: * The testsuite will probably fail everywhere, because of some warnings that happen during the linking phase when you invoke the built compiler. So the testsuite runner will probably be unhappy. Clang is very noisy about unused options, unlike GCC. That needs to be fixed somewhere in DriverPipeline I'd guess, but with some refactoring. * Some of the stage2 libraries don't build due to a Clang bug. These are vector/primitive/dph so far. * There is no buildbot or anything to cover it. You will need a very recent Clang. Due to this bug (preventing primitive etc from building,) you'll preferably want to use an SVN checkout from about 6 hours ago at latest: http://llvm.org/bugs/show_bug.cgi?id=16363 Hilariously, this bug was tripped on primitive's Data.Primitive.Types module due to some CPP weirdness. But even with a proper bugfix and no segfault, it still fails to correctly parse this same module with the same CPP declarations. I'm fairly certain this is another bug in Clang, but I might be wrong. I'm trying to isolate it. Unfortunately Clang/LLVM 3.3 was just released and it won't see bugfix releases. But it will *probably* work if we just get rid of the CPP tomfoolery in primitive. I'll be testing it in the next few days to see if we can get 3.3 supported. (I'm sort of kicking myself in the head for not doing this a week or two ago...) Anyway, there are some rough edges but it should be in shape for 7.8 I hope. It should be especially welcome for Mac users. (I'm also hoping modern Macs could even go all-clang-all-the-time if my fix for #7602 can go in soon...) PS. If you use ASSERT, I just fixed a lot of instances of using that macro, involving whitespace between the name and arguments (commit d8ee2b.) Clang does not forgive you for this. Should I note this anywhere for the future in the wiki or something? -- Regards, Austin - PGP: 4096R/0x91384671

8 16

cminusminus.org is down ... (thats the only host of the c-- spec right?)
by Carter Schonwald 29 Jun '13

29 Jun '13

Hey All, the c-- site that hosts the c-- spec seems to be down / gone. This probably doesn't matter *too* much, but it'd be a shame to no longer have the spec for *full* c-- online as a rubric to compare ghc cmm against. could someone who perhaps actively chats with/or knows Norman Ramsey or whichever of his students was maintaining / hosting it ask about that? Seems a shame to have it offline...

1 1