- ghc-devs - Haskell.org

Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
by Herbert Valerio Riedel 22 Apr '14

22 Apr '14

Hello *, Now that GHC 7.8.[12] is out of the door, the Git reorganization can be tackled further... After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago): - base - ghc-prim - integer-gmp - integer-simple - template-haskell IMO, the benefit/cost ratio of simplifying the workflow outweighs the benefit/cost ratio of turning those into proper Git submodules. This incremental step towards a fully git-bisect-able ghc.git does already allow bisecting to work on a larger time-range than it does now, as those wired-in packages are the most likely to break compilation if out-of-sync with ghc.git. If no objections are raised, I'm planning to implement this change next weekend (April 19th/20th). Any comments/questions/...? Cheers, hvr PS: After this step, the next remaining step would be to turn the remaining not-yet-submodule Git repos into proper submodule Repos (like haddock.git) and figure out how to get the sync-all convenience-tooling a bit more submodule friendly...

5 8

Validate Failures
by Daniel Fischer 22 Apr '14

22 Apr '14

I'm getting three or four validate failures on 64-bit Linux (openSuSE 12.3): Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) simplCore/should_compile simpl015 [exit code non-0] (optasm) th T8333 [bad stdout] (normal) The perf tests allocate about 2% more than they are allowed to. > bytes allocated value is too high: > Expected bytes allocated: 308422280 +/-5% > Lower bound bytes allocated: 293001166 > Upper bound bytes allocated: 323843394 > Actual bytes allocated: 329638208 > *** unexpected failure for T3064(normal) > bytes allocated value is too high: > Expected bytes allocated: 110646312 +/-10% > Lower bound bytes allocated: 99581680 > Upper bound bytes allocated: 121710944 > Actual bytes allocated: 123103232 > *** unexpected failure for T6048(optasm) The T8333 failure is due to it reading my .ghci file, thus getting additional output. Is there a way to automatically check that all tests that use the "--interactive" flag also use "-ignore-dot-ghci" like the ghci tests do, or must one wait for validate failures due to that and add it then? Finally, simpl015 is a test that does only sometimes fail. It uses on my box an estimated 2GB of memory, and when I haven't anything else memory-hungry running, it passes, but when I have (as I do by default) SeaMonkey running (with tons of open tabs), my box quasi-freezes, the test times out, and the browser is OOM-killed. I am not happy with that behaviour. And looking at what the test is, I am somewhat irritated that it uses so much memory. Cheers, Daniel

2 2

update "latest" user manual
by Richard Eisenberg 22 Apr '14

22 Apr '14

Hi devs, I’m not sure who is responsible for this (Austin? Herbert?), but http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to v7.8.1, though 7.8.2 is available. We should update. Thanks, Richard

3 3

Strange behaviour in my signum
by Alexander Berntsen 21 Apr '14

21 Apr '14

I started preparing patches for #7858. My abs patch works well, my signum patch not at all. The gist of the bug is that abs and signum return erroneous values for for the input -0.0. abs (-0.0 :: Float) should return 0.0, not -0.0. My patch fixes this. For signum the situation is reverse. My patch does *not* fix this. It does not work using GHC nor GHCi (GHCi -ddump-simpl demonstrated below). The code for my signum is correct, as may be demonstrated by putting signumFix x | x == 0.0 = x | isNaN x = x | x > 0.0 = 1 | otherwise = negate 1 in a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0 :: Float) should now return -0.0, where signum returns 0.0 with the same argument. Following this email come the patches. Please review the second patch. If you can spot what I am doing wrong, I would be grateful. Prelude> abs (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aqt :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aqt = GHC.Num.abs @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aqt `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Prelude> signum (-0.0 :: Float) ==================== Simplified expression ==================== let { it_aKQ :: GHC.Types.Float [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Arity=0, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] it_aKQ = GHC.Num.signum @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Num.negate @ GHC.Types.Float GHC.Float.$fNumFloat (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_aKQ `cast` (UnivCo representational GHC.Types.Float () :: GHC.Types.Float ~# ())) (GHC.Types.[] @ ()))) 0.0 Alexander Berntsen (2): Make Prelude.abs handle -0.0 correctly (#7858) Make Prelude.signum handle -0.0 correctly (#7858) libraries/base/GHC/Float.lhs | 28 ++++++++++++++++++---------- libraries/base/changelog.md | 2 ++ 2 files changed, 20 insertions(+), 10 deletions(-) -- 1.8.3.2

2 3

RE: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d)
by Simon Peyton Jones 21 Apr '14

21 Apr '14

There is much more to change, right? * The code in the compiler that implements -fwarn-amp * Actually making Applicative a superclass of monad Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 20 April 2014 07:02 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for | validate (6074c5d) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e | c4955735931/ghc | | >--------------------------------------------------------------- | | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Sun Apr 20 01:00:44 2014 -0500 | | Remove -fno-warn-amp sledgehammers for validate | | GHC should now fully compliant with respect to the Applicative | Monad | proposal (including all upstream libraries), and does not need to | suppress this warning anymore. | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 6074c5da7f48f10e9b3b88d14607ec4955735931 | mk/validate-settings.mk | 2 -- | 1 file changed, 2 deletions(-) | | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index | 8797bf9..cac938d 100644 | --- a/mk/validate-settings.mk | +++ b/mk/validate-settings.mk | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | | GhcStage1HcOpts += -fwarn-tabs | GhcStage2HcOpts += -fwarn-tabs | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the | tests, and faster building of the utils to be installed | | GhcLibHcOpts += -O -dcore-lint | -GhcLibHcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | # We define DefaultFastGhcLibWays in this style so that the value is | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

RE: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)
by Simon Peyton Jones 21 Apr '14

21 Apr '14

I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 20 April 2014 22:56 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163/ghc | | >--------------------------------------------------------------- | | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Sun Apr 20 01:10:15 2014 -0500 | | Deprecate the AMP warnings. | | Now that we're in development mode, Applicative will soon be a | superclass of Monad in HEAD. So let's go ahead and deprecate the | -fno-warn-amp flag, remove the checks, and tweak a few tests | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 3608f657d55b7ea7dd711556a4faf6a15c509163 | compiler/main/DynFlags.hs | 4 +- | compiler/typecheck/TcRnDriver.lhs | 215 +----------- | -------- | docs/users_guide/flags.xml | 2 +- | .../tests/ghci.debugger/scripts/break006.stderr | 4 +- | .../tests/ghci.debugger/scripts/print019.stderr | 2 +- | .../should_fail/overloadedlistsfail01.stderr | 2 +- | testsuite/tests/rename/should_compile/T7145b.hs | 3 - | .../tests/rename/should_compile/T7145b.stderr | 2 +- | .../tests/simplCore/should_compile/spec001.hs | 3 +- | .../tests/typecheck/should_compile/holes2.stderr | 2 +- | testsuite/tests/typecheck/should_fail/T5095.stderr | 2 - | .../tests/typecheck/should_fail/tcfail072.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail133.stderr | 2 +- | .../tests/typecheck/should_fail/tcfail181.stderr | 1 - | 14 files changed, 14 insertions(+), 232 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 3608f657d55b7ea7dd711556a4faf6a15c509163 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

Heap usage of GHC increased in 7.8 vs. 7.6
by Simon Marlow 19 Apr '14

19 Apr '14

I noticed that T1969 is failing again, and decided to do a little investigation. The maximum residency when compiling T1969 with HEAD compared with 7.6.3 looks like this: 7.6.3: 10,473,920 HEAD: 13,783,536 This is with +RTS -h -i0.01 to avoid sampling errors as much as possible. The figures are pretty accurate, and the heap profiles confirm it: we're using a lot more heap now. -ddump-if-trace shows that HEAD is reading more interface files: Renamer stats: 10 interfaces read 6 type/class/variable imported, out of 1361 read 0 instance decls imported, out of 105 read 0 rule decls imported, out of 53 read vs. with 7.6.3: Renamer stats: 8 interfaces read 2 type/class/variable imported, out of 828 read 0 instance decls imported, out of 40 read 0 rule decls imported, out of 45 read The extra interface files are Control.Applicative and Control.Monad. So the question is, why are we now reading these on *every* compilation? (T1969 imports only the Prelude). Presumably this is something to do with the AMP warnings, but can't we lazily load these interfaces when they're needed? Cheers, Simon

3 4

Proposal - Foreign enum support
by Merijn Verstraaten 19 Apr '14

19 Apr '14

Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support =============================== At the moment the FFI does not have a convenient way with interacting enums (whether proper enums or CPP defines) in C (like languages). Both enums and CPP defined enums are major parts of large C APIs and they are thus crucial to writing foreign bindings. A few examples: SDL_image defines the following enum: typedef enum { IMG_INIT_JPG = 0x00000001, IMG_INIT_PNG = 0x00000002, IMG_INIT_TIF = 0x00000004, IMG_INIT_WEBP = 0x00000008 } IMG_InitFlags; OpenCL specifies the following typedefs + CPP defined enum: typedef uint32_t cl_uint __attribute__((aligned(4))); typedef cl_uint cl_platform_info; /* cl_platform_info */ #define CL_PLATFORM_PROFILE 0x0900 #define CL_PLATFORM_VERSION 0x0901 #define CL_PLATFORM_NAME 0x0902 #define CL_PLATFORM_VENDOR 0x0903 #define CL_PLATFORM_EXTENSIONS 0x0904 OpenCL functions will return the above CPP defines as return values of type cl_platform_info. Current Solutions ----------------- In many cases someone wrapping such a C library would like to expose these enums as a simple sum type as this has several benefits: type safety, the ability to use haskell constructors for pattern matching, exhaustiveness checks. Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set of foreign types and newtypes with exposed constructors of these types. As such there seem two approaches to wrap these enums: 1. Implement an ADT representing the enum and write a manual conversion function between the ADT and the corresponding C type (e.g. CInt -> Foo and Foo -> CInt). 2. Use a tool like c2hs to automatically generate the ADT and conversion function. In both cases the foreign functions are imported using the corresponding C type in their signature (reducing type safety) and the user is forced write trivial wrappers for every imported function to convert the ADT to the relevant C type and back. This is both tedious to write and costly in terms of code produced, in case of c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every argument/result even though this could trivially be a no-op. Worse, since c2hs uses the Enum class for it's conversion to/from C types it generates Enum instances like: instance Enum Foo where fromEnum Bar = 1 fromEnum Baz = 1337 toEnum 1 = Bar toEnum 1337 = Baz toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) Since succ/pred and enumFromTo's default implementations assume enums convert to continuous sequence of Int this means the default generated enum instances crash. This problem could be overcome by making c2hs' code generation smarter, but this does not eliminate the tediousness of wrapping all foreign imported functions with marshalling wrappers, NOR does it eliminate the overhead of all this useless marshalling. Proposal -------- Add a new foreign construct for enums, the syntax I propose below is rather ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining based on a concrete example. foreign enum CInt as Foo where Bar = 1 Baz Quux = 1337 Xyzzy = _ This would introduce a new type 'Foo' with semantics approximately equivalent too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". Explicit listing of the value corresponding to a constructor should be optional, missing values should just increment by one from the previous (like C), if the initial value is missing, it should assume to start from 0. Values do not need to be contiguous. Users should be able to use these constructors as normal in pattern match (really, this mostly follows to semantics of the above pattern synonyms). The foreign import/export functionality should invisibly marshall Foo to the underlying foreign type (as is done for newtypes). I'm unsure about the support for a wildcard constructor like Xyzzy. If there is support for a wildcard, it should be optional. On the upside a wildcard means the marshalling is no longer a partial function. The downside is that it makes desugaring the use of enums in patterns harder. It seems clear that f Xyzzy = {- ... -} f Bar = {- ... -} f Baz = {- ... -} f Quux = {- ... -} Should not have the same semantics as: f (Foo _) = {- ... -} f (Foo 1) = {- ... -} f (Foo 2) = {- ... -} f (Foo 1337) = {- ... -} So in the presence of wildcards, the Foo enum can't trivially be desugared into pattern synonyms after checking exhaustiveness. Pros: 1. Foreign imports are slightly more type safe, as one can now write: foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () Preventing users from passing an arbitrary CInt to an argument expecting a specific enum. 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness checks and pattern matching 3. Cheaper as marshalling Foo to CInt is a no-op 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int mapping is no longer used for marshalling Cons: 1. Non-standard extension of the FFI 2. Someone has to implement it 3. Wildcards constructors would present difficulties desugaring pattern matches to a simple newtype. 4. ?? What Would Need to be Done? --------------------------- 1. Parser needs to be extended to deal with parsing of enum declarations. 2. Pattern matches of an enum type need to be checked for exhaustiveness and desugared to the underlying type's representation. 3. Extend foreign imports/exports to marshall enums properly. If there's no objections I'm willing to take a stab at implementing this, although I'd probably need some help with GHC's internals (although I could bug #ghc for that). Cheers, Merijn

5 6

Cannot locally 'sync-all get'
by Daniel Fischer 19 Apr '14

19 Apr '14

Like so often, ./sync-all pull failed today in my local clones, first with "... not on a branch", after sync-all checkout master, with "fatal: Reference ... not a tree". (Aside, that nonsense didn't happen before the introduction of submodules.) The usual remedy is rm -rf ./clone git clone ./ghc ./clone cd clone ./sync-all get but today it failed with > Klone nach 'libraries/xhtml'... > Fertig. > Unterprojekt-Pfad: 'libraries/xhtml': > 'fb9e0bbb69e15873682a9f25d39652099a3ccac1' ausgecheckt fatal: Projektarchiv > '/home/dafis/GHC/./haddock.git' existiert nicht. Klonen von > '/home/dafis/GHC/./haddock.git' in Unterprojekt-Pfad 'utils/haddock' > fehlgeschlagen git failed: 256 at ./sync-all line 123. Any idea what's up? Cheers, Daniel

2 2

RE: OverloadedRecordFields
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense Simon | -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/

4 4