July 2014 - ghc-devs - Haskell.org

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