- ghc-devs - Haskell.org

GHC 7.8.3 release
by Austin Seipp 03 Jul '14

03 Jul '14

Hello all, After a long week, I've finally gotten a little time to reply to emails, and I mainly have one question I'd like to ask. First, please direct your attention to this: https://ghc.haskell.org/trac/ghc/query?status=closed&status=merge&status=pa… This is the 7.8.3 milestone, but it only considers things that are: - 1) Fixed - 2) Going to be merged - 3) Are a patch to be still merged. That is, it is a solid representation of the difference between 7.8.2 and the 7.8 branch tip. The question is: when should we do the release? There are several bugs there that seem quite problematic for users - #9045, #7097, #9001, #8768 and #9078 in particular. If these bugs are really problematic (and I sort of feel they are) then the release can happen soon. I can do it within a week from now, and we could punt more to a 7.8.4 release. I ask this because my time to dedicate to GHC is a bit thin right now, so you must help me decide what's important! So please let me know - just a general vote in favor of doing it within some X timeframe (even 'real soon' or 'a week would be great') would be nice. PS: I apologize for the lack of status updates and brief email - my time for GHC has been in very short order the past two weeks in particular, and I've finally just returned to a computer (not mine) for right now to ask this. PPS: This might also impact the 7.10 schedule, but last Simon and I talked, we thought perhaps shooting for ICFP this time (and actually hitting it) was a good plan. So I'd estimate on that a 7.8.4 might happen a few months from now, after summer. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 21

Help needed: parsing pattern synonym contexts
by Dr. ERDI Gergo 02 Jul '14

02 Jul '14

Hi, I'm working on adding type signatures to pattern synonyms. The syntax I'm after would look something like, e.g.: pattern (Eq b) => P Int (Bool, b) (f [a]) :: (Show a) => Maybe [a] My problem is with parsing the two contexts. I wrote the parser in the following way, which I felt natural (actions omitted for brevity) pattern_synonym_sig :: { LSig RdrName } : 'pattern' patsyn_context patsyn_stuff '::' patsyn_context type patsyn_stuff :: { Located (Located RdrName, HsPatSynDetails (LHsType RdrName)) } : constr_stuff patsyn_context :: { LHsContext RdrName } : {- empty -} | forall context '=>' However, this doesn't work, no matter if those contexts are present or not. If I remove both contexts from the rules, i.e. if I replace pattern_synonym_sig with : 'pattern' patsyn_stuff '::' type then parsing succeeds when there are no contexts on either side. I've also tried : 'pattern' patsyn_stuff '::' ctype with the intention of recovering the required context from the ctype (and I could do similar tricks to get the provided context from the patsyn_stuff by using a modified version of constr_stuff); however, even that doesn't work as I expected it, i.e. with this latter version, this: pattern Single a :: (Eq a) => [a] fails with a parse error on "::". Can someone help me out here please? Thanks, Gergo

4 8

Code redundancy in PrelNames?
by Jan Stolarek 02 Jul '14

02 Jul '14

I'm looking at PrelNames.lhs and I believe there is some redundancy that can also lead to confusion. Consider these definitions: bindMName = methName gHC_BASE (fsLit ">>=") bindMClassOpKey arrAName = varQual aRROW (fsLit "arr") arrAIdKey Former is defined as "methName", while the latter is "varQual". These are defined like this: varQual :: Module -> FastString -> Unique -> Name varQual = mk_known_key_name varName mk_known_key_name :: NameSpace -> Module -> FastString -> Unique -> Name mk_known_key_name space modu str unique = mkExternalName unique modu (mkOccNameFS space str) noSrcSpan methName :: Module -> FastString -> Unique -> Name methName modu occ unique = mkExternalName unique modu (mkVarOccFS occ) noSrcSpan Expanding the call to mk_known_key_name in varQual the RHS of varQual becomes : mkExternalName unique modu (mkOccNameFS varName str) noSrcSpan Now, the call to "mkVarOccFS occ" in methName resolves to "mkOccNameFS varName occ", making the call to varQual identical to methName. Is this redundancy a conscious choice or just an accident? If it's conscious then what is the purpose? I spent several minutes trying to understand why bindMName and arrAName are defined differently. Names suggest that bindMName is a method, while arrAName is a qualified variable. I find this confusing and I think it would be better to drop varQual in favour of methName. Thoughts? Janek

2 1

Fixing Trac #9046 (Panic in GHCi when using :print).
by Vitaly Bragilevsky 02 Jul '14

02 Jul '14

Hello, I am trying to fix the bug #9046 (Panic in GHCi when using :print). I've discovered that It was introduced by this SPJ's commit (25 Nov 2013): https://ghc.haskell.org/trac/ghc/changeset/a8ac471d435214dbdc1fa70f938c6312… and especially by this change: -type QuantifiedType = ([TyVar], Type) -- Make the free type variables explicit +type QuantifiedType = ([TyVar], Type) + -- Make the free type variables explicit + -- The returned Type should have no top-level foralls (I believe) quantifyType :: Type -> QuantifiedType --- Generalize the type: find all free tyvars and wrap in the appropiate ForAll. -quantifyType ty = (varSetElems (tyVarsOfType ty), ty) +-- Generalize the type: find all free and forall'd tyvars +-- and return them, together with the type inside, which +-- should not be a forall type. +-- +-- Thus (quantifyType (forall a. a->[b])) +-- returns ([a,b], a -> [b]) + +quantifyType ty = (varSetElems (tyVarsOfType rho), rho) + where + (_tvs, rho) = tcSplitForAllTys ty While this change looks reasonable to me it breaks exploiting thunks created by `:print` ghci's command from polymorphic values. Before this change we could have: $ ghci -fprint-explicit-foralls GHCi, version 7.6.3.20130421: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::forall a. [a] -> Int) > _t1 [1,2,3] 3 And now we have: $ ghci -fprint-explicit-foralls GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > :print length length = (_t1::[a] -> Int) > _t1 [1,2,3] ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcTyVarDetails a{tv arw} [tv] This particular panic is caused by unification (compiler/typecheck/TcUnify.lhs line 1042). In case of `read` instead of `length` we get panic even earlier in simplification (compiler/typecheck/TcSimplify line 85). The concrete reason for the panic is wrong constructor used for tyvar (TyVar instead of TcTyVar). I see several ways to fix this: 1) rollback to forall-types in `:print` (requires change in cvObtainTerm, RtClosureInspect.hs); 2) skolemise free tyvar to RuntimeUnk (it becomes TcTyVar then): a) in cvObtainTerm; b) somewhere before typechecking. I can't decide the correct way to fix this bug or maybe there are other alternatives. Anyway I am ready to work on this though I need some advice. With best regards, Vitaly Bragilevsky

2 1

Why we need CCS entries in apply functions (rts/Apply.cmm and rts/StgStdThunks.cmm)
by Ömer Sinan Ağacan 01 Jul '14

01 Jul '14

Hi all, Code for entering cost-centres before executing the function/thunk body is generated in `compiler/codeGen/StgCmmBind.hs`, by `thunkCode` and `closureCodeBody` functions. But we also have some `enterCostCentreThunk` and `enterCostCentreFun` calls in `rts/Apply.cmm` and `rts/StgStdThunks.cmm`. I'm wondering why are those necessary. Thunk/function bodies already have CCS entries generated by functions in StgCmmBind so I'm having trouble seeing the need for this additional entries. Can anyone explain those to me? Thanks, --- Ömer Sinan Ağacan http://osa1.net

1 0

the case of the missing Cabal doc
by Mark Lentczner 01 Jul '14

01 Jul '14

In times of yore (prior to 7.8), when GHC build a bindist, it included the generated HTML manual for Cabal. As of 7.8, this seems to have gone missing-in-action. Anyone know where it went? - Mark

2 2

HEADS-UP: Git submodule conversion imminent
by Herbert Valerio Riedel 01 Jul '14

01 Jul '14

Hello GHC Devs! In order to not drag this out any longer, I'll completing the submodule conversion in the next few hours by converting the remaining sub-repo packages into proper submodules. This is represents phase 1 of the reorganization (phase 2 comprises officially transitioning the push-urls of *some* the packages to github.com/haskell as happened with haddock). However, this phase 1 is important to get done early (ideally half a year ago) in order to make 'ghc-complete' bit more redundant (I hope Joachim doesn't mind... :-) ) and allow to properly 'git bisect' as far back as possible into the past. While the workflow changes[1] to additionally have the sub-repo change also registed in ghc.git, practically, this should affect only a minority of you, as the remaining packages (see list at the bottom of this mail) to be converted into submodules are modified *very* seldom. This will be similiar to the conversion of haddock.git into a proper submodule of which you read up in * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4049> * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4072> * <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4077> List of packages converted into proper submodules: * libffi-tarballs libffi-tarballs.git * utils/hsc2hs hsc2hs.git * libraries/array packages/array.git * libraries/deepseq packages/deepseq.git * libraries/directory packages/directory.git * libraries/filepath packages/filepath.git * libraries/haskell98 packages/haskell98.git * libraries/haskell2010 packages/haskell2010.git * libraries/hoopl packages/hoopl.git * libraries/hpc packages/hpc.git * libraries/old-locale packages/old-locale.git * libraries/old-time packages/old-time.git * libraries/process packages/process.git * libraries/unix packages/unix.git * nofib nofib.git * libraries/parallel packages/parallel.git * libraries/stm packages/stm.git * libraries/dph packages/dph.git Ideally, you won't have any outstanding changes in those repos (hint, hint!) to make the transition for your GHC clones easier. I'll follow up with more specific instructions as soon as I've pushed the changes. N.B.: ghc-tarballs will *not* become a submodule, as it would impose a non-neglible cost on everyone, not only the developers on windows and, moreover, the plan is to turn ghc-tarballs into a scripted download (or maybe something git-annex based) as Git is not really suited for such large blobs. See also discussion at <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/4895> [1]: For the new workflow in case you really happen to have to touch one of the affected modules, see the work-in-progress Wiki entry at https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Mak…

8 20

Re: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea)
by Herbert Valerio Riedel 01 Jul '14

01 Jul '14

Hi, Fyi, this changeset seems to have broken ./validate: utils/haddock/src/Haddock/Interface/Rename.hs:449:11: Warning: Fields of ‘ClsInstDecl’ not initialised: cid_overlap_mode In the first argument of ‘return’, namely ‘(ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'})’ In a stmt of a 'do' block: return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) In the expression: do { ltype' <- renameLType ltype; lATs' <- mapM (mapM renameTyFamInstD) lATs; lADTs' <- mapM (mapM renameDataFamInstD) lADTs; return (ClsInstDecl {cid_poly_ty = ltype', cid_binds = emptyBag, cid_sigs = [], cid_tyfam_insts = lATs', cid_datafam_insts = lADTs'}) } <no location info>: Failing due to -Werror. make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] Error 1 make: *** [all] Error 2 On 2014-06-30 at 02:37:52 +0200, git-4Dsf34iY/NkouOHNgZ69ag(a)public.gmane.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/6290eeadf61a40f2eb08d0fd7ef1f3b7f… > >>--------------------------------------------------------------- > > commit 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > Author: Iavor S. Diatchki <iavor.diatchki(a)gmail.com> > Date: Sun Jun 29 17:22:16 2014 -0700 > > Overlapable pragmas for individual instances (#9242) > > Programmers may provide a pragma immediately after the `instance` keyword > to control the overlap/incoherence behavior for individual instances. > For example: > > instance {-# OVERLAP #-} C a where ... > > I chose this notation, rather than the other two outlined in the ticket > for these reasons: > > 1. Having the pragma after the type looks odd, I think. > 2. Having the pragma after there `where` does not work for > stand-alone derived instances > > I have implemented 3 pragams: > > 1. NO_OVERLAP > 2. OVERLAP > 3. INCOHERENT > > These correspond directly to the internal modes currently supported by > GHC. If a pragma is specified, it will be used no matter what flags are > turned on. For example, putting `NO_OVERLAP` on an instance will mark > it as non-overlapping, even if `OVERLAPPIN_INSTANCES` is turned on for the > module. > > >>--------------------------------------------------------------- > > 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 > compiler/hsSyn/Convert.lhs | 2 +- > compiler/hsSyn/HsDecls.lhs | 24 ++++++++++++++++---- > compiler/parser/Lexer.x | 6 +++++ > compiler/parser/Parser.y.pp | 21 +++++++++++++----- > compiler/rename/RnSource.lhs | 7 ++++-- > compiler/typecheck/TcDeriv.lhs | 46 +++++++++++++++++++++++++-------------- > compiler/typecheck/TcInstDcls.lhs | 5 ++++- > 7 files changed, 82 insertions(+), 29 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 6290eeadf61a40f2eb08d0fd7ef1f3b7f9804178 -- "Elegance is not optional" -- Richard O'Keefe

3 3

Two days old build breakage on i386.
by Karel Gardas 30 Jun '14

30 Jun '14

Hello, builders running on i386 building for this platform caught issue which shows as a build breakage: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140624 for i386-unknown-linux): RegAllocLinear.allocRegsAndSpill: no spill candidates allocating vreg: VirtualRegI n1Q6 assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))] freeRegs: FreeRegs 4282318848 initFreeRegs: FreeRegs 4282318861 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1 libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed Have a look for example on linux-i386 buildot log here: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS independent and probably 32bit/i386 platform specific and it's two days old breakage now. The last two night builds fail on all mentioned buildbots. I'm not sure but perhaps: commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3 Author: Johan Tibell <johan.tibell(a)gmail.com> Date: Mon Jun 9 11:43:21 2014 +0200 triggers that issue? I'm not claiming that the commit is actual culprit, this may be just recently un-hidden issue in linear regs allocator on i386! Thanks! Karel

7 21

Resolved+new Q: TypeLits question, how to build a Type Application with Symbol index
by Gabor Greif 30 Jun '14

30 Jun '14

I succeeded to solve all of them :-) But now I am blocked on on a panic "not in scope during type checking, but it passed the renamer". I suspect that while "deriving Generic" some instances are defined in some empty TcEnv, which does not contain my definition in context. Is there a way to inject some type constructor into the TcEnv? Thanks, Gabor On 6/27/14, Gabor Greif <ggreif(a)gmail.com> wrote: > Hello devs, > > I have > > {{{ > data D (n :: Symbol) > }}} > > in my module, and I want to obtain a type > > {{{ > D "YAY!" > }}} > > programmatically. Where can I find code that performs this (or > something similar)? > > 1) I have to look up |D| in the current TyEnv (what if it is in a > specific module?), > 2) I have to build the type index (of kind Symbol), this involves > FastString, looks non-trivial, > 3) Apply 1) on 2), this is easy. > > Any hints welcome! > > Thanks and cheers, > > Gabor > > > PS: some morsels I have so far: > > for 1) > compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit > "GHC.Generics") >

2 3