November 2015 - ghc-devs

Re: [ANNOUNCE] 7.10.3 release candidate 2 - problems compiling source on Mac OS with clang
by George Colpitts 09 Nov '15

09 Nov '15

redid with just make rather than make -j5. I get ... chmod +x libraries/integer-gmp2/gmp/ln # Their cmd invocation only works on msys. On cygwin it starts # a cmd interactive shell. The replacement works in both environments. mv libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig sed 's#cmd //c echo "\$1"#cmd /c "echo $1"#' < libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh.orig > libraries/integer-gmp2/gmp/gmpbuild/ltmain.sh cd libraries/integer-gmp2/gmp; (set -o igncr 2>/dev/null) && set -o igncr; export SHELLOPTS; \ PATH=`pwd`:$PATH; \ export PATH; \ cd gmpbuild && \ CC=clang NM=/usr/bin/nm AR=/usr/bin/ar ./configure \ --enable-shared=no \ --host=x86_64-apple-darwin --build=x86_64-apple-darwin /bin/sh: SHELLOPTS: readonly variable checking build system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking host system type... /bin/sh: SHELLOPTS: readonly variable /bin/sh: SHELLOPTS: readonly variable x86_64-apple-darwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes /bin/sh: SHELLOPTS: readonly variable checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking ABI=64 checking whether clang is gcc... yes checking compiler clang -O2 -pedantic -fPIC -m64 ... no, gnupro alpha ev6 char spilling checking ABI=32 checking whether clang is gcc... yes *checking compiler clang -m32 -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *checking compiler clang -O2 -pedantic -fPIC -fomit-frame-pointer ... no, gnupro alpha ev6 char spilling* *configure: error: could not find a working compiler, see config.log for details* *make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1* *make: *** [all] Error 2* On Mon, Nov 9, 2015 at 9:32 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > George Colpitts <george.colpitts(a)gmail.com> writes: > > > I get > > > > make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > It looks like the build failed somewhere before this point. Could you > provide a more complete log? > > Cheers, > > - Ben > > >

1 0

Printing local Var(Id) types(in Outputable outputs)
by Ömer Sinan Ağacan 06 Nov '15

06 Nov '15

Hi all, I'm considering getting into the trouble of implementing this: A flag for printing types of local Ids. To be more specific, I'd like to see types of local Ids and binders in case expression alternatives etc. I may name it -dshow-local-id-types or something like that. An example output would be like this. Instead of: case ds_dPC of _ [Occ=Dead] { C1 l_avq -> ... C2 r_avr -> ... } It would print: case ds_dPC of _ [Occ=Dead] { C1 (l_avq :: Type1) -> ... C2 (r_avr :: Type2) -> ... } So my questions are: * Do we already have something like this? (I can't see it in man page) * Do you think, for some reason, this would be useless? (maybe there's some workaround etc. that has a similar effect) Thanks.

3 2

Implied GHC extensions (in HEAD)
by Gabor Greif 06 Nov '15

06 Nov '15

Hi devs, when compiling a snippet of code (which I have written using GHC HEAD) with GHC 7.10.2 (from the platform) I got errors about missing extension pragmas. I had to add two: > {-# LANGUAGE ViewPatterns, KindSignatures, GADTs, PolyKinds, StandaloneDeriving, FlexibleContexts, FlexibleInstances, ScopedTypeVariables, TypeFamilies, PatternSynonyms, FunctionalDependencies, RankNTypes, UndecidableInstances #-} > {-# LANGUAGE DataKinds, TypeOperators #-} -- 7.10?? Looks like the implications have been extended in 7.11. I guess PolyKinds now implies DataKinds, but cannot think of what implies TypeOperators. Was this change by design or by accident? Any ideas? Cheers, Gabor

1 0

Evaluating types and determining instantiability of an instance
by Jan Bracker 06 Nov '15

06 Nov '15

Hello, I am trying to write a type checker plugin and I noticed that I keep trying to reimplement functionality that GHC type system already implements, but I can't seem to find a way to access the functionality. Part of these features I already asked in another (previous) email [1] to the mailing list and I am sorry if this will duplicate part of that discussion. 1. Is there a function in the type system which I can use to evaluate type functions and expand type synonyms (including associated instances)? Ideally I would want something that looks like this 'Type -> TcM Type'. I know that this kind of evaluation is not necessarily possible (e.g. type variables that can't be matched against in a type function application), but it would be helpful if the function could at least evaluate/expand as far as is possible in the current context. That way I don't have to manually lookup type family instances or type synonyms and make mistakes by doing so. This would also ease the support for the different type system extensions available, which I currently have to manually reimplement. 2. If I have an instance and a number of type arguments for that instance, is there an easy way to check if that instance is instantiated by those arguments? Something of the form '[Ct] -> ClsInst -> [Type] -> TcM (Maybe EvTerm)' would be useful. This function would take the given and derived constraints and deliver evidence for the instantiation if it is possible or return nothing if it is not. Again, if there are some open type variables I know this is not always possible in general and I am aware that this, in its full generality, requires a call to the constraint solver. But currently I am manually walking through the instance constraints to check if they are instantiated given the arguments [3] and then I also manually produce evidence [2]. In that process I ignore type equalities, type synonym and type families, because that would require me to implement question 1. I suspect this kind of functionality should exists somewhere within the GHC API. I would want this function to work with type arguments, whose only type variables already occur in the given and derived constraints. I think in that case it should always be possible to determine if the instance is instantiated. Best regards, Jan Bracker [1] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010342.html [2] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo… [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo…

3 2

Type Checker Plugin: Producing the correct evidence
by Jan Bracker 05 Nov '15

05 Nov '15

Hello, I am using type checker plugins to select specific instances in a program. My current problem concerns the following instance: class Polymonad m n p where (>>=) :: m a -> (a -> n b) -> p b instance ( Effect m, E.Inv m f (Unit m), f ~ Plus m f (Unit m)) => Polymonad (m (f :: [*])) Identity (m (f :: [*])) where ma >>= f = ma E.>>= (E.return . runIdentity . f) 'E', 'Unit' and 'Plus' refer to the module 'Control.Effect' [5] from the 'effect-monad' package. At some point in my example program [2] GHC is uncertain which instance to use for the '>>=' operator. The wanted constraint is: [W] $dPolymonad_a5Qp :: Polymonad (State '[n :-> (a :! 'W)]) Identity (State '[n :-> (a :! 'W)]) (CNonCanonical) To select the instance above I produce the following evidence: $fPolymonadmIdentitym @[State, '[n :-> (a :! 'W)]] [$fEffect[]State @[] []] 'State' is from the module 'Control.Effect.State' [4]. This works so far, but during the core-lint phase I get the following error message: <no location info>: Warning: [RHS of $dPolymonad_a5Qp :: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)])] The type of this binder doesn't match the type of its RHS: $dPolymonad_a5Qp Binder's type: Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Rhs type: (Inv State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State), '[n_a5PL :-> (a_a5PM :! 'W)] ~ Plus State '[n_a5PL :-> (a_a5PM :! 'W)] (Unit State)) => Polymonad (State '[n_a5PL :-> (a_a5PM :! 'W)]) Identity (State '[n_a5PL :-> (a_a5PM :! 'W)]) Which I parse as a missing proof that the instance constraints are fulfilled by the evidence. >From this I have a few questions: 1. Why doesn't the type checker prove these type equality constraints for me? (or how can I get the type checker to do so?) I checked them on paper and the constraints are solvable and the equalities are true. 2. If I can't get the type checker to solve this for me, how do I produce appropriate evidence? 3. Another issue I see is that I would need to expand the type synonym 'E.Inv' to see what constraints it contains. I there an easy way to do so in GHC? I could not find appropriate functionality. It would be very useful for me if there was a function 'Type -> TcM Type' that evaluates the type as far as possible (by evaluate I mean expand synonyms, evaluate type functions and remove equalities that hold). The example program [2] and the plugin I am developing can be found [1] on GitHub (Commit fefc149ec6e1c1a3c3c2597c66d176854b94287d ). This is how I produce the evidence for my selected instance [3]. I hope this abstract description of my problem is enough. Best regards, Jan Bracker [1] https://github.com/jbracker/polymonad-plugin [2] https://github.com/jbracker/polymonad-plugin/blob/master/examples/effect/Ma… [3] https://github.com/jbracker/polymonad-plugin/blob/master/src/Control/Polymo… [4] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect-S… [5] http://hackage.haskell.org/package/effect-monad-0.6.1/docs/Control-Effect.h…

1 0

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