- ghc-devs - Haskell.org

10 Sep '13

1 0

Trac 8244 (remove the dependency on Cabal)
by JP Moresmau 09 Sep '13

09 Sep '13

Hello, I've been looking at http://ghc.haskell.org/trac/ghc/ticket/8244, following the discussions: -http://www.mail-archive.com/haskell-cafe@haskell.org/msg107850.html -http://www.haskell.org/pipermail/ghc-devs/2013-March/000762.html This is basically about the fact that GHC-as-a-library as a dependency on the Cabal library, which causes all kinds of grief for tools using the GHC API (can't upgrade Cabal). The ticket has a nice dependency diagram, thanks to lemao. So I tried to see what could work. This is what I've done so far: - created a new distribution-base library (the name avoids any reference to Cabal, don't know if it's wise) - build that library instead of Cabal in stage0 and stage1 - reference that library instead of Cabal in ghc.cabal, pkg-pkg.cabal, Cabal.Cabal - add the dependency when building ghc-cabal and ghc-tags, both need the full Cabal anyway. The distribution-base library contains the following modules: - Distribution.Compat.ParseUtils: the bits of Cabal's Distribution.ParseUtils we need - Distribution.Compat.ReadP: Cabal's ReadP - Distribution.InstalledPackageInfo: Cabal's Distribution.InstalledPackageInfo - Distribution.License: Cabal's Distribution.License - Distribution.ModuleName: Cabal's Distribution.ModuleName - Distribution.Package: Cabal's Distribution.Package minus the Dependency type and related functions (unused in GHC) - Distribution.PackageIndex: the bits of Cabal's Distribution.Simple.PackageIndex we need - Distribution.Text: Cabal's Distribution.Text - Distribution.Utils: the bits of Cabal's Distribution.Simple.Utils we need Note that Distribution.Version is not needed by GHC, even though it used to import it, it only used the datatype from base, and the Data instance I've moved to Distribution.Package. I've created a new Cabal module called Distribution.Dependency since the Dependency type is not needed, in the Cabal source code it's mainly imports that need to change. All seems to build on my machine. It doesn't really help the build itself since Cabal is still needed for ghc-cabal, but at least the GHC API does not require the Cabal library any more. What do you think? Is it a step in the right direction? Thanks JP -- JP Moresmau http://jpmoresmau.blogspot.com/

1 0

OverloadedRecordFields status update
by Adam Gundry 09 Sep '13

09 Sep '13

Hi ghc-devs, I have been working on a new extension, OverloadedRecordFields, and it is now essentially feature-complete. Unfortunately, I doubt it will make it into 7.8, as the changes are quite extensive, but I hope to get it in HEAD soon thereafter. I would really appreciate comments on the design [1], for which there is a prototype implementation [2] that works in GHC 7.6.3. If you'd like to review the code, you can check out the overloaded-record-fields branch from the Github repositories [3, 4], and there are notes on the implementation on the wiki [5]. Thanks! Adam [1] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan [2] https://github.com/adamgundry/records-prototype [3] https://github.com/adamgundry/ghc [4] https://github.com/adamgundry/packages-base [5] http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Impleme…

2 4

Alex and new Bool primops
by Jan Stolarek 09 Sep '13

09 Sep '13

I am refactoring new Bool primops (#6135). There was a discussion on core-libraries-commitee list and the decision was made that we should keep names of primops we used so far and change their type signature (right now HEAD has different names for new primops and reuses old names for compatibility wrappers). I've changed names of the primops and removed the wrappers but I can't bootstrap GHC because old primops are hardwired into Alex. I get this build error when attempting to build stage 2 compiler: compiler/stage2/build/Lexer.hs:2348:34: Couldn't match expected type ‛Bool’ with actual type ‛Int#’ In the first argument of ‛(&&)’, namely ‛(offset >=# 0#)’ In the expression: (offset >=# 0#) && (check ==# ord_c) In the expression: if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s compiler/stage2/build/Lexer.hs:2348:53: Couldn't match expected type ‛Bool’ with actual type ‛Int#’ In the second argument of ‛(&&)’, namely ‛(check ==# ord_c)’ In the expression: (offset >=# 0#) && (check ==# ord_c) In the expression: if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s And indeed, looking at Lexer.hs I see: alex_scan_tkn user orig_input len input s last_acc = (...) -- some irrelevant code here (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) then alexIndexInt16OffAddr alex_table offset else alexIndexInt16OffAddr alex_deflt s So to compile GHC, Alex would need to generate different code for GHC 7.6.3 and below, and different for GHC 7.7 and above (or alternatively it could generate #if pragmas), but this means we'd need to update Alex. I created compatibility module within GHC called ExtsCompat46 and tried adding it to list of imported modules, but in generated Lexer.hs Alex adds a bunch of other modules among which is GHC.Exts, which conflicts with import of ExtsCompat46: compiler/stage1/build/Lexer.hs:2349:41: Ambiguous occurrence `>=#' It could refer to either `ExtsCompat46.>=#', imported from `ExtsCompat46' at compiler/parser/Lexer.x:79:1-19 or `GHC.Exts.>=#', imported from `GHC.Exts' at compiler/stage1/build/Lexer.hs:75:1-15 (and originally defined in `ghc-prim:GHC.Prim') Again, we would need updated version of Alex to generate correct code (also, this would break in the future after removing that compatibility module). I don't see a way out of this. Help? Janek

3 4

RE: newtype wrappers
by Simon Peyton-Jones 09 Sep '13

09 Sep '13

| However, there is perhaps a middle road: what if much of the | infrastructure is merged, without the user-facing feature? From a user's | point of view, these coercions feel much more like a library than a | language feature. Yes, the instances appear out of thin air, but | otherwise, the 'coerce' function is totally normal-looking. Unless I'm | mistaken, there is no new syntax. If we merge much (all?) of the | implementation but don't export "coerce" and "Coercible" anywhere, then we | can continue to tinker with the design in HEAD, and perhaps release with | 7.8.2. Does that make sense? Yes. We did this with type families in 7.4. Much of the infrastructure was there, but it wasn't an advertised feature so we did not feel constrained (for example) to apply bug fixes to the 7.4 branch. Let's do the same here. Essentially a full impl, but simply not advertised. OK? Note to other ghc-devs. The issue under discussion is whether to merge Joachim's "newtype wrapper" feature. I'm keen to do so because it's very cool. But arguably the design needs some time to "settle". Proposed outcome is to merge the code but not advertise the feature, like we did for type functions in 7.4. Simon | | Richard | | On Sep 7, 2013, at 1:41 PM, Simon Peyton-Jones <simonpj(a)microsoft.com> | wrote: | | > For a release we want | > * A stable design | > * An implementation that works pretty reliably | > It doesn't have to do everything; and we can improve the impl | incrementally. | > | > Let's see what Richard thinks | > | > Simon | > | > | -----Original Message----- | > | From: Joachim Breitner [mailto:mail@joachim-breitner.de] | > | Sent: 07 September 2013 18:37 | > | To: Simon Peyton-Jones | > | Cc: Richard Eisenberg (eir(a)cis.upenn.edu) | > | Subject: Re: newtype wrappers | > | | > | Hi, | > | | > | Am Samstag, den 07.09.2013, 17:17 +0000 schrieb Simon Peyton-Jones: | > | > I'm beginning to think that newtype wrappers might be done enough to | > | > put into 7.8. (Feature freeze is on Friday.) | > | > | > | > What do you think? It's a very attractive new feature, and fits | > | > nicely with the new roles. | > | | > | I'm reluctant; I haven't even started to think what happens when I try | > | to coerce between more fancy stuff like newtype families. Maybe it all | > | works smoothly (after all, this is Haskell and the code typechecks), | but | > | I'm not too confident. | > | | > | Furthermore there is some code smell in the way I mark the newtype | > | constructors as used, where I had to drill a hole in the TcS | > | abstraction. | > | | > | If you are not worried about these, then it just remains to | > | * extend the user documentation and | > | * add coerce and Coercible to GHC.Exts. | > | which is certainly possible to do until Friday. | > | | > | Greetings, | > | Joachim | > | | > | -- | > | Joachim "nomeata" Breitner | > | mail(a)joachim-breitner.de * http://www.joachim-breitner.de/ | > | Jabber: nomeata(a)joachim-breitner.de * GPG-Key: 0x4743206C | > | Debian Developer: nomeata(a)debian.org | >

2 1

A build problem on Mac
by Kazu Yamamoto 09 Sep '13

09 Sep '13

Hi, I cannot build GHC head on Mac today: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-7.7.20130907 -hide-all-packages -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/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/deSugar/Coverage.lhs -o compiler/stage2/build/Coverage.o -dyno compiler/stage2/build/Coverage.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130907 for i386-apple-darwin): expectJust block_order Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/build/Parser.o] Error 1 make[1]: *** Deleting file `compiler/stage2/build/Parser.o' make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 --Kazu

4 11

Dynamic libraries on Mac
by Kazu Yamamoto 09 Sep '13

09 Sep '13

Hi, I built GHC head today (with d61c3ac186c94021c851f7a2a6d20631e35fc1ba reverted). While I'm supporting GHC head for "doctest" on Mac, I found the following problems relating to dynamic linking: (1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g. % otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base libHSbase-4.7.0.0-ghc7.7.20130909.dylib: /Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) (2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g. % otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users /Users/kazu/work/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/primitive/dist-install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) (3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g. % otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users /Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc-paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) This means that programs complied GHC head do not work if I execute "make clean" in the GHC build directory. --Kazu

1 0

Testsuite run dynamic and not
by Edward Z. Yang 08 Sep '13

08 Sep '13

Hey folks, I'm writing a test for #5435 but I don't really know how to structure it properly. I have a C file and an HS file, and I'd like to run the test twice: once dynamic (so the C should be compiled with -fPIC) and once not. Furthermore, I'd like both ways to run when doing 'make fast' (unless dynamic libraries are not available). How do I spell this? The easy thing is to list the test twice in all.T but this seems wrong. Edward

2 1

熟悉办公事务的处理技巧
by 干立雨 08 Sep '13

08 Sep '13

1 0

Haddock fails during validation because "GHC/Types.hs is not loaded"
by David Luposchainsky 06 Sep '13

06 Sep '13

I've run into an issue with Haddock that prevents me from validating further. The last 100 lines of the build output: http://lpaste.net/92627 The file it claims not to have loaded exists, and so do many others like "GHC.IntWord64" that Haddock doesn't seem to have a problem with in line 88. I've tried running "sh validate" from scratch again, but unfortunately that didn't work either. Searching online for similar problems shows other people had this in the past (with different modules), but no solution is mentioned. Has anyone run into a similar problem recently and could help me out with this? David

1 0