- ghc-devs - Haskell.org

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1
by Peter Trommler 05 Nov '15

05 Nov '15

Sent from the wrong account the first time around. > On 04.11.2015, at 17:18, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > > > On Nov 4, 2015, at 11:12 AM, Peter Trommler <Peter.Trommler(a)th-nuernberg.de> wrote: > >> It looks like a bug to me. > > I'm taking your "it" here to mean the fact that GHC is looking for readelf on a Mac OS platform. Yes. That's correct. Peter

3 3

Status of OverloadedRecordFields [Was: Re: Proposal: Dot as Postfix Function Apply]
by Adam Gundry 05 Nov '15

05 Nov '15

[copying ghc-devs as the following is perhaps more relevant there] On 04/11/15 10:44, Jeremy wrote: > Dot as Postfix Function Apply > (https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField…) > was originally part of ORF, but dropped to keep the scope/discussion more > manageable. Now that ORF is in for GHC 8.0, I would like to re-propose dot > postfix syntax. I'm going to stay out of the discussion over the proposed syntax extension, but I feel like I should do some expectation management about ORF in GHC 8.0. As the wiki page [1] makes clear, ORF has been divided into three components, and so far only one of these is in GHC HEAD. The first part is a language extension, DuplicateRecordFields, which allows field names to be duplicated provided they are unambiguous. (It does not allow any kind of polymorphism over record fields.) This is already in HEAD. The second part is another language extension, OverloadedLabels, which introduces a new syntax #x for an identifier whose type is inferred and may depend on the text of the identifier. This is implemented and up on Phabricator [2], but not yet in HEAD. It should make GHC 8.0, but I'm wary about giving cast-iron guarantees. The third part, which is necessary for the OverloadedLabels syntax to be used for polymorphism over record fields, involves typeclass constraints that capture when a type has a particular field, with the instances provided automatically by GHC. This is not yet implemented in the intended form, and is unlikely to make GHC 8.0 (barring me having a sudden outbreak of free time...). Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [2] https://phabricator.haskell.org/D1331 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

[ANNOUNCE] GHC 7.10.3 release candidate 1
by Ben Gamari 04 Nov '15

04 Nov '15

We are pleased to announce the first (and hopefully only) release candidate for GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc1/ This includes the source tarball and bindists for 64-bit and 32-bit modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x97DB64AD). As always, our content delivery network tends to be a bit slow on the uptake. If you see an empty directory at this URL just add a few superfluous slashes to the end; this is typically enough to fool it. The 7.10.2 release was well-behaved save a couple notable bugs; while we have merged a good number of bug fixes in 7.10.3 they were were largely low risk and so we expect that this release should be similiarly stable. The one exception to this is an upgrade of the Windows compiler toolchain to GCC 5.2. Windows users have been long suffering at the hand of our old toolchain (e.g. lack of response file support, #8596, and lack of SEH support) so we expect that this change should fix far more than breaks. We plan to make the 7.10.3 release sometime next week. Please test this as much as possible; bugs are much cheaper if we find them before the release and this will ideally be the last release of the 7.10 series. Happy testing, - Ben

9 12

Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]'
by Joachim Breitner 03 Nov '15

03 Nov '15

Hi, I cannot build ghc-7.10.3 on Debian armel: "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 Erik, can you comment on that? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

4 5

A big patch
by Simon Peyton Jones 03 Nov '15

03 Nov '15

Ben, Austin I wonder if one of you could put up a big patch on Phab for me? I started about two months ago on a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. It's time to finish! I could just commit, but it's good practice to put it on Phab first. Could you do that for me? · It's in branch wip/spj-wildcard-refactor · It's up to date with HEAD from a day or two back · The principal driving change is described in Note [HsType binders] in HsType. Worth reading! Those data type changes drive almost everything else. · There are some uninteresting knock-on changes in Haddock, which are in wip/spj-wildcard-refactor in utils/haddock. I've done the submodule commit thing so the ghc-repo branch should refer correctly to the Haddock branch. · The commit log on the branch is of no interest; just dump it entirely. I will write a proper commit message in due course. · A handful of tests are failing. I'm working on that, but I want to get this onto Phab now awyway. You could include this email as the Phab description. Thanks! Simon

3 2

process library broken on Windows
by Simon Peyton Jones 02 Nov '15

02 Nov '15

I'm getting this on HEAD in te ' libraries\process\System\Process\Internals.hs:106:16: warning: Defined but not used: data constructor 'CGid' Indeed it looks as if CGId(..) should be exported, else createProcess is unusuable. This looks like the right change. Would someone like to check and make the change Simon diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 5575ac4..3e23ad5 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -37,6 +37,8 @@ module System.Process.Internals ( #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) pPrPr_disableITimers, c_execvpe, ignoreSignal, defaultSignal, +#else + CGid(..), GroupID, UserID, #endif withFilePathException, withCEnvironment, translate,

3 8

Better calling conventions for strict functions (bang patterns)?
by Ryan Newton 02 Nov '15

02 Nov '15

Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function arguments were enforced by caller or callee. Here's a Gist that shows the compilation of a trivial function: foo :: Maybe Int -> Intfoo !x = case x of Just y -> y https://gist.github.com/rrnewton/1ac722189c65f26fe9ac If that function is compiled to *assume* its input is in WHNF, it should be just as efficient as the isomorphic MLton/OCaml code, right? It only needs to branch on the tag, do a field dereference, and return. But as you can see from the STG and CMM generated, foo *does indeed* enter the thunk, adding an extra indirect jump. Here's the body: c3aY: if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c3aO; else goto c3aP; c3aP: call (I64[R1])(R1) returns to c3aO, args: 8, res: 8, upd: 8; c3aO: if (R1 & 7 >= 2) goto c3aW; else goto c3aX; c3aW: R1 = P64[R1 + 6] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c3aX: R1 = PicBaseReg + lvl_r39S_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; The call inside c3aP is entering "x" as a thunk, which also incurs all of the stack limit check code. I believe that IF the input could be assumed to be in WHNF, everything above the label "c3aO" could be omitted. So... if GHC is going to be a fabulous pure *and* imperative language, and a fabulous lazy *and* strict compiler/runtime.. is there some work we can do here to improve this situation? Would the following make sense: - Put together a benchmark suite of all-strict programs with Strict/StrictData (compare a few benchmark's generated code to MLton, if time allows) - Modify GHC to change calling conventions for bang patterns -- caller enforces WHNF rather than callee. Existing strictness/demand/cardinality analysis would stay the same. Unless there's something I'm really missing here, the result should be that you can have a whole chain of strict function calls, each of which knows its arguments and the arguments it passes to its callees are all in WHNF, without ever generating thunk-entry sequences. Thanks for your time, -Ryan

6 12

Proposal: accept pull requests on GitHub
by Thomas Miedema 02 Nov '15

02 Nov '15

Hello all, my arguments against Phabricator are here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator. Some quotes from #ghc to pique your curiosity (there are some 50 more): * "is arc broken today?" * "arc is a frickin' mystery." * "i have a theory that i've managed to create a revision that phab can't handle." * "Diffs just seem to be too expensive to create ... I can't blame contributors for not wanting to do this for every atomic change" * "but seriously, we can't require this for contributing to GHC... the entry barrier is already high enough" GitHub has side-by-side diffs <https://github.com/blog/1884-introducing-split-diffs> nowadays, and Travis-CI can run `./validate --fast` comfortably <https://travis-ci.org/ghc/ghc/builds>. *Proposal: accept pull requests from contributors on https://github.com/ghc/ghc <https://github.com/ghc/ghc>.* Details: * use Travis-CI to validate pull requests. * keep using the Trac issue tracker (contributors are encouraged to put a link to their pull-request in the 'Differential Revisions' field). * keep using the Trac wiki. * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself. * keep pushing to git.haskell.org, where the existing Git receive hooks can do their job keeping tabs, trailing whitespace and dangling submodule references out, notify Trac and send emails. Committers close pull-requests manually, just like they do Trac tickets. * keep running Phabricator for as long as necessary. * mention that pull requests are accepted on https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs. My expectation is that the majority of patches will start coming in via pull requests, the number of contributions will go up, commits will be smaller, and there will be more of them per pull request (contributors will be able to put style changes and refactorings into separate commits, without jumping through a bunch of hoops). Reviewers will get many more emails. Other arguments against GitHub are here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub. I probably missed a few things, so fire away. Thanks, Thomas

16 20

Re: [commit: ghc] master: Kill redundant import (da58d15)
by Herbert Valerio Riedel 30 Oct '15

30 Oct '15

originally, http://git.haskell.org/ghc.git/commitdiff/7eb5e29b4a7b6fef55512bc7bf3308e71… the import looked like this: import qualified HsSyn -- hack as we want to reexport the whole module import HsSyn hiding ((<.>)) so it wasn't redundant back then at least. > commit da58d1517ce9c57514f7b2bd7d444c9e3051a717 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Fri Oct 30 09:45:16 2015 +0000 > > Kill redundant import > > I don't really understand this. GHC.hs had: > > module GHC( ..., module HsSyn, ... ) where > import HsSyn > import qualified HsSyn -- hack as we want to reexport the whole module > > GHC now reports the 'import qualified' line as redundant; and it certainly > is, because 'import HsSyn' brings everything into scope qualified *and* > unqualified. I have no idea why the "hack" was necessary before, but > following my refactoring of tcg_used_gres (previous commit), it's reported > as redundant, so I've deleted it. > > I'm making it a separate commit because it seems a bit mysterious and I > wanted to draw attention to it.

1 0

Documenting record pattern synonyms
by Simon Peyton Jones 30 Oct '15

30 Oct '15

Matthew: Could you please write the user-manual sections that you have promised? That is, the *specification* this feature. Currently, so far as I can see, there is literally NO user manual documentation. No changes to docs/users_guide whatsoever. We have discussed this on several occasions, and you agreed to do it. I sat with you in person and showed you what I have in mind. There is a sketch on the wiki page. I did not intend this patch to land until the user documentation was done. Now I feel as if I've lost my leverage :-). But it really really really really needs doing. Please. I'm begging you. Compared to what you have already done, it's easy. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 29 October 2015 11:25 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Record pattern synonyms (2a74a64) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell. | org%2ftrac%2fghc%2fchangeset%2f2a74a64e8329ab9e0c74bec47198cb492d25affb%2fgh | c&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3abb08d2 | e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nEAgwVmvFQNgN%2bANGD4H | z1flN%2fucKSRFoZMdhRqQKSM%3d | | >--------------------------------------------------------------- | | commit 2a74a64e8329ab9e0c74bec47198cb492d25affb | Author: Matthew Pickering <matthewtpickering(a)gmail.com> | Date: Mon Oct 19 21:17:29 2015 +0100 | | Record pattern synonyms | | This patch implements an extension to pattern synonyms which allows user | to specify pattern synonyms using record syntax. Doing so generates | appropriate selectors and update functions. | | === Interaction with Duplicate Record Fields === | | The implementation given here isn't quite as general as it could be with | respect to the recently-introduced `DuplicateRecordFields` extension. | | Consider the following module: | | {-# LANGUAGE DuplicateRecordFields #-} | {-# LANGUAGE PatternSynonyms #-} | | module Main where | | pattern S{a, b} = (a, b) | pattern T{a} = Just a | | main = do | print S{ a = "fst", b = "snd" } | print T{ a = "a" } | | In principle, this ought to work, because there is no ambiguity. But at | the moment it leads to a "multiple declarations of a" error. The problem | is that pattern synonym record selectors don't do the same name mangling | as normal datatypes when DuplicateRecordFields is enabled. They could, | but this would require some work to track the field label and selector | name separately. | | In particular, we currently represent datatype selectors in the third | component of AvailTC, but pattern synonym selectors are just represented | as Avails (because they don't have a corresponding type constructor). | Moreover, the GlobalRdrElt for a selector currently requires it to have | a parent tycon. | | (example due to Adam Gundry) | | === Updating Explicitly Bidirectional Pattern Synonyms === | | Consider the following | | ``` | pattern Silly{a} <- [a] where | Silly a = [a, a] | | f1 = a [5] -- 5 | | f2 = [5] {a = 6} -- currently [6,6] | ``` | | === Fixing Polymorphic Updates === | | They were fixed by adding these two lines in `dsExpr`. This might break | record updates but will be easy to fix. | | ``` | + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) | | - , pat_wrap = idHsWrapper } | +, pat_wrap = req_wrap } | ``` | | === Mixed selectors error === | | Note [Mixed Record Field Updates] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | Consider the following pattern synonym. | | data MyRec = MyRec { foo :: Int, qux :: String } | | pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} | | This allows updates such as the following | | updater :: MyRec -> MyRec | updater a = a {f1 = 1 } | | It would also make sense to allow the following update (which we | reject). | | updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" | | This leads to confusing behaviour when the selectors in fact refer the | same field. | | updater a = a {f1 = 1, foo = 2} ==? ??? | | For this reason, we reject a mixture of pattern synonym and normal | record selectors in the same update block. Although of course we still | allow the following. | | updater a = (a {f1 = 1}) {foo = 2} | | > updater (MyRec 0 "str") | MyRec 2 "str" | | | >--------------------------------------------------------------- | | 2a74a64e8329ab9e0c74bec47198cb492d25affb | compiler/basicTypes/ConLike.hs | 86 +++++++- | compiler/basicTypes/ConLike.hs-boot | 18 ++ | compiler/basicTypes/Id.hs | 31 ++- | compiler/basicTypes/IdInfo.hs | 21 +- | compiler/basicTypes/PatSyn.hs | 51 +++-- | compiler/deSugar/Coverage.hs | 11 +- | compiler/deSugar/DsExpr.hs | 79 ++++--- | compiler/deSugar/DsMeta.hs | 2 +- | compiler/hsSyn/Convert.hs | 10 +- | compiler/hsSyn/HsBinds.hs | 67 +++++- | compiler/hsSyn/HsExpr.hs | 35 +++- | compiler/hsSyn/HsUtils.hs | 21 +- | compiler/hsSyn/PlaceHolder.hs | 6 +- | compiler/iface/BuildTyCl.hs | 7 +- | compiler/iface/IfaceSyn.hs | 17 +- | compiler/iface/MkIface.hs | 11 +- | compiler/iface/TcIface.hs | 12 +- | compiler/main/HscTypes.hs | 15 +- | compiler/parser/Parser.y | 28 ++- | compiler/parser/RdrHsSyn.hs | 2 +- | compiler/prelude/TysWiredIn.hs | 2 +- | compiler/rename/RnBinds.hs | 18 +- | compiler/rename/RnExpr.hs | 8 +- | compiler/rename/RnNames.hs | 30 +-- | compiler/rename/RnSource.hs | 52 ++++- | compiler/typecheck/TcBinds.hs | 6 +- | compiler/typecheck/TcExpr.hs | 231 +++++++++++++++--- | --- | compiler/typecheck/TcHsSyn.hs | 10 +- | compiler/typecheck/TcPat.hs | 6 +- | compiler/typecheck/TcPatSyn.hs | 124 ++++++++--- | compiler/typecheck/TcPatSyn.hs-boot | 8 +- | compiler/typecheck/TcRnDriver.hs | 3 +- | compiler/typecheck/TcTyClsDecls.hs | 39 ++-- | compiler/types/TyCon.hs | 7 +- | compiler/types/TypeRep.hs | 2 +- | compiler/types/TypeRep.hs-boot | 1 + | testsuite/tests/patsyn/should_compile/all.T | 7 +- | .../tests/patsyn/should_compile/records-compile.hs | 11 + | .../tests/patsyn/should_compile/records-poly.hs | 16 ++ | .../patsyn/should_compile/records-prov-req.hs | 26 +++ | .../patsyn/should_compile/records-req-only.hs | 16 ++ | .../tests/patsyn/should_compile/records-req.hs | 14 ++ | testsuite/tests/patsyn/should_fail/all.T | 7 + | .../should_fail/mixed-pat-syn-record-sels.hs | 9 + | .../should_fail/mixed-pat-syn-record-sels.stderr | 5 + | .../tests/patsyn/should_fail/records-check-sels.hs | 10 + | .../patsyn/should_fail/records-check-sels.stderr | 3 + | .../tests/patsyn/should_fail/records-exquant.hs | 10 + | .../patsyn/should_fail/records-exquant.stderr | 11 + | .../patsyn/should_fail/records-mixing-fields.hs | 12 ++ | .../should_fail/records-mixing-fields.stderr | 17 ++ | .../patsyn/should_fail/records-no-uni-update.hs | 7 + | .../should_fail/records-no-uni-update.stderr | 5 + | .../patsyn/should_fail/records-no-uni-update2.hs | 11 + | .../should_fail/records-no-uni-update2.stderr | 5 + | .../patsyn/should_fail/records-poly-update.hs | 13 ++ | .../patsyn/should_fail/records-poly-update.stderr | 5 + | testsuite/tests/patsyn/should_run/all.T | 1 + | testsuite/tests/patsyn/should_run/records-run.hs | 14 ++ | .../tests/patsyn/should_run/records-run.stdout | 5 + | 60 files changed, 1055 insertions(+), 262 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 2a74a64e8329ab9e0c74bec47198cb492d25affb | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0deecf24e85641ff3a | bb08d2e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ymzeKEsSAnOhr4QL | ngFKt0e8B84voue20%2bCyMPwWf%2fQ%3d

2 2