- ghc-devs - Haskell.org

Unused type variables with non-linear patterns
by Jan Stolarek 15 Dec '15

15 Dec '15

An intersting thing came up when implementing warnings for unused type variables in type family patterns (#10982 / D1576): type family X a b where X a a = Int Should we emit a warning that `a` is unused? It does not appear in the RHS but it is actually used because of non-linear pattern. We can fix this by prefixing both appearances of `a` with an underscore - this silences the warning and maintains semantics. Nevertheless, if a variable is unused it should be perfectly valid to replace it with an underscore - that is not the case in this example. Thoughts? Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

4 4

Warning suppression pragmas
by Эдгар Жаворонков 15 Dec '15

15 Dec '15

Hello devs! I am trying to implement some kind of local warnings suppresion and i need some help. I want to use a pragma to mark functions so compiler won't throw warnings from them. I defined my pragma in lexer, parser and added type signature in HsBinds.hs. And i am stuck. I don't know what to do. What should i consider doing further? I designed a small wiki page here - https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas So if you have nice examples, feel free to add them. Thanks for your help in advance! --- С уважением, Жаворонков Эдгар Best regards, Edgar A. Zhavoronkov

4 4

-XStrict: Why some binders are not made strict?
by Ömer Sinan Ağacan 15 Dec '15

15 Dec '15

Let's say I have this code: zip :: [a] -> [b] -> [(a, b)] zip [] [] = [] zip (x : xs) (y : ys) = (x, y) : zip xs ys With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering about the motivation behind this, I found this interesting. I always thought -XStrict gives me this guarantee: If I'm using an already-defined variable(bound by a let or pattern matching) in an expression, I can be sure that the variable won't be bottom in that expression, because it would be `seq`d before the expression is evaluated. So if I have case ... of D x y -> <body> or let x = ... y = ... in <body> In both cases I was thinking that in <body> 'x' and 'y' can't be bottom(with -XStrict). This would make -XStrict programs evaluate like they would in a call-by-value language(even though in the RTS level thunks will be built). Variables can't range over computations; all binders evaluated strictly etc. Can anyone tell me about the motivation behind this decision? I think the wiki page actually conflicts with itself. It says "... bindings to be strict by default" but then in "case expressions" sections says case x of (a,b) -> rhs is interpreted as case x of !(a,b) -> rhs Here bindings 'a' and 'b' are not made strict. I'd expect something like: case x of (!a,!b) -> rhs (Which seems to be invalid Haskell, but same effect could be achieved with `seq a (seq b rhs)`) Thanks.. (I also realized that the wiki page doesn't mention bindings in do syntax, is it because this case is implied by "function definitions"? That is, bangs are added after do syntax is desugared and so they become strict?)

6 16

RE: [commit: ghc] master: Make sure PatSyns only get added once to tcg_patsyns (41ef8f7)
by Simon Peyton Jones 15 Dec '15

15 Dec '15

Good catch Matthew! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 11 December 2015 18:12 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Make sure PatSyns only get added once | to tcg_patsyns (41ef8f7) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha | skell.org%2ftrac%2fghc%2fchangeset%2f41ef8f70819e9b99aacc6d81019e5a33a | 63dfeab%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265 | a98dcc44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat | a=aH%2bCJDOGW%2f2iqa%2fVNndOfAq2bJfBRBGiCADHYBzt5Uc%3d | | >--------------------------------------------------------------- | | commit 41ef8f70819e9b99aacc6d81019e5a33a63dfeab | Author: Matthew Pickering <matthewtpickering(a)gmail.com> | Date: Fri Dec 11 18:10:45 2015 +0000 | | Make sure PatSyns only get added once to tcg_patsyns | | Summary: Before, `PatSyn`s were getting added twice to | `tcg_patsyns` so | when inspecting afterwards there were duplicates in the list. | This makes sure that only they only get added once. | | Reviewers: austin, bgamari | | Reviewed By: bgamari | | Subscribers: thomie | | Differential Revision: https://phabricator.haskell.org/D1597 | | | >--------------------------------------------------------------- | | 41ef8f70819e9b99aacc6d81019e5a33a63dfeab | compiler/typecheck/TcBinds.hs | 8 +++----- | compiler/typecheck/TcPatSyn.hs | 10 +++++----- | compiler/typecheck/TcPatSyn.hs-boot | 7 +++---- | 3 files changed, 11 insertions(+), 14 deletions(-) | | diff --git a/compiler/typecheck/TcBinds.hs | b/compiler/typecheck/TcBinds.hs index 673109b..1254b78 100644 | --- a/compiler/typecheck/TcBinds.hs | +++ b/compiler/typecheck/TcBinds.hs | @@ -49,7 +49,6 @@ import NameSet | import NameEnv | import SrcLoc | import Bag | -import PatSyn | import ListSetOps | import ErrUtils | import Digraph | @@ -483,13 +482,12 @@ tc_single :: forall thing. | -> LHsBind Name -> TcM thing | -> TcM (LHsBinds TcId, thing) tc_single _top_lvl sig_fn | _prag_fn (L _ (PatSynBind psb@PSB{ psb_id = L _ name })) thing_inside | - = do { (pat_syn, aux_binds, tcg_env) <- tc_pat_syn_decl | - ; let tything = AConLike (PatSynCon pat_syn) | - ; thing <- setGblEnv tcg_env $ tcExtendGlobalEnv [tything] | thing_inside | + = do { (aux_binds, tcg_env) <- tc_pat_syn_decl | + ; thing <- setGblEnv tcg_env thing_inside | ; return (aux_binds, thing) | } | where | - tc_pat_syn_decl :: TcM (PatSyn, LHsBinds TcId, TcGblEnv) | + tc_pat_syn_decl :: TcM (LHsBinds TcId, TcGblEnv) | tc_pat_syn_decl = case sig_fn name of | Nothing -> tcInferPatSynDecl psb | Just (TcPatSynSig tpsi) -> tcCheckPatSynDecl psb tpsi diff -- | git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs | index 30dcbf7..69eeef0 100644 | --- a/compiler/typecheck/TcPatSyn.hs | +++ b/compiler/typecheck/TcPatSyn.hs | @@ -61,7 +61,7 @@ import Control.Monad (forM) -} | | tcInferPatSynDecl :: PatSynBind Name Name | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tcInferPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | psb_def = lpat, psb_dir = dir } | = setSrcSpan loc $ | @@ -96,7 +96,7 @@ tcInferPatSynDecl PSB{ psb_id = lname@(L loc name), | psb_args = details, | | tcCheckPatSynDecl :: PatSynBind Name Name | -> TcPatSynInfo | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | psb_def = lpat, psb_dir = dir } | TPSI{ patsig_tau = tau, @@ -163,7 +163,7 @@ | tcCheckPatSynDecl PSB{ psb_id = lname@(L loc name), psb_args = | details, | (univ_tvs, req_theta, req_ev_binds, | req_dicts) | (ex_tvs, ex_tys, prov_theta, prov_ev_binds, | prov_dicts) | wrapped_args | - pat_ty rec_fields } | + pat_ty rec_fields } | where | (arg_tys, pat_ty) = tcSplitFunTys tau | | @@ -199,7 +199,7 @@ tc_patsyn_finish :: Located Name -- ^ PatSyn Name | -> TcType -- ^ Pattern type | -> [Name] -- ^ Selector names | -- ^ Whether fields, empty if not record PatSyn | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | tc_patsyn_finish lname dir is_infix lpat' | (univ_tvs, req_theta, req_ev_binds, req_dicts) | (ex_tvs, subst, prov_theta, prov_ev_binds, | prov_dicts) @@ -262,7 +262,7 @@ tc_patsyn_finish lname dir is_infix | lpat' | tcRecSelBinds | (ValBindsOut (zip (repeat NonRecursive) selector_binds) | sigs) | | - ; return (patSyn, matcher_bind, tcg_env) } | + ; return (matcher_bind, tcg_env) } | | where | zonk_wrapped_arg :: (Var, HsWrapper) -> TcM (Var, HsWrapper) diff | --git a/compiler/typecheck/TcPatSyn.hs-boot | b/compiler/typecheck/TcPatSyn.hs-boot | index 61f7958..11c1bc1 100644 | --- a/compiler/typecheck/TcPatSyn.hs-boot | +++ b/compiler/typecheck/TcPatSyn.hs-boot | @@ -4,16 +4,15 @@ import Name ( Name ) | import Id ( Id ) | import HsSyn ( PatSynBind, LHsBinds ) | import TcRnTypes ( TcM, TcPatSynInfo ) | -import PatSyn ( PatSyn ) | -import TcRnMonad ( TcGblEnv ) | +import TcRnMonad ( TcGblEnv) | import Outputable ( Outputable ) | | tcInferPatSynDecl :: PatSynBind Name Name | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | | tcCheckPatSynDecl :: PatSynBind Name Name | -> TcPatSynInfo | - -> TcM (PatSyn, LHsBinds Id, TcGblEnv) | + -> TcM (LHsBinds Id, TcGblEnv) | | tcPatSynBuilderBind :: PatSynBind Name Name | -> TcM (LHsBinds Id) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd98265a98dcc | 44ba27f808d30256abde%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B6Hb | JaANWHnlqhBaZ5AOMvHAQ0Mzs4t8cvtkQLIo4t4%3d

1 0

Re: GHC 8.0 feature freeze imminent
by Ryan Scott 14 Dec '15

14 Dec '15

One thing I definitely want to get in before the 8.0 release is: * A fix for Trac #10716 [1] (adding strictness metadata to GHC generics). This feels like a natural counterpart for Trac #10697 [2] (reworking strictness information to Template Haskell), which currently has a Phab Diff in review [3]. I'd like for these to be released at the same time so that I can use Template Haskell to backport the machinery in generic-deriving [4]. In addition, I realized that my encoding of selector metadata is not very extensible at the moment, and this would give me a good excuse to fix it. Some things that I probably won't get in time for 8.0: * Automatic derivation of Bifunctor/Bifoldable/Bitraversable, and of Eq1/Eq2/Ord1/Ord2/Read1/Read2/Show1/Show2. These would require resolving Trac #10448 [5] and #11135 [6] first, which might need more discussion. Not only that, but I still need to write up a proposal for how each of these classes would be derived, and there would need to be additional discussion on those points... All in all, it doesn't sound like something I could do in two weeks :) * Making Generic1 kind-polymorphic, Trac #10604 [7]. The first step to achieving this was done recently [8], but unfortunately, I wasn't able to make the actual datatypes in GHC.Generics kind-polymorphic for unknown reasons (I'd still like to talk to Richard Eisenberg about this at some point). Not only that, but I'm not sure what the implications of making Generic1 poly-kinded would be yet. I'd like to talk to Andres Löh about this. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10716 [2] https://ghc.haskell.org/trac/ghc/ticket/10697 [3] https://phabricator.haskell.org/D1605 [4] http://hackage.haskell.org/package/generic-deriving [5] https://ghc.haskell.org/trac/ghc/ticket/10448 [6] https://ghc.haskell.org/trac/ghc/ticket/11135 [7] https://ghc.haskell.org/trac/ghc/ticket/10604 [8] https://ghc.haskell.org/trac/ghc/ticket/10775

3 2

Remaining type=kind items
by Richard Eisenberg 14 Dec '15

14 Dec '15

Yes -- these are very much on the TODO list. Sadly, visible type application didn't make it. It could with another two weeks(?), but I don't think it's worth holding things up further. Unlike D808, visible type application doesn't touch wide swaths of code, so merging it after the ghc-8.0 branch won't cause backporting trouble. I plan on writing a longish section in the user manual about GHC's kind system, updating the PolyKinds discussion already there. Should happen this week. Richard On Dec 14, 2015, at 8:32 AM, Ben Gamari <ben(a)smart-cactus.org> wrote: > Hi Richard! > > This is probably on your to-do list, but here are a few > places where I think the no-kinds work could use some documentation, > > - the introduction of kind equalities could use a brief note in the > release notes > > - visible type application should be mentioned in the release notes > (this made it in, right?) > > - visible type application syntax should be described in the users > guide > > - `-XTypeInType` needs some discussion in the users guide. Be sure > to mention the fact that `*` needs to be imported explicitly and > state precisely how one would do this (since it is a symbol) > > - the notion of levity could use a bit of discussion in the users > guide > > Cheers, > > - Ben

1 0

Re: Performance of pattern checker on OptCoercions
by Richard Eisenberg 12 Dec '15

12 Dec '15

Here's a thought: is there a way you can tell when you're in a bad case? There's surely one easy way: just count how many times your algorithm goes around. But perhaps you can do better, by looking for lots of guards, etc. My idea would be to enable guard checking by default, but to bail when the going gets tough. Bailing could issue a warning that such-and-such a function/case/multi-way-if is too ornate to be checked performantly. The user could then specify `-fno-warn-incomplete-pattern-guards` to turn off pattern-guard checking, `-fno-warn-ornate-guards` simply to disable the warning in the too-tough-to-handle case (but still check other guards in the module), or `-fwarn-incomplete-pattern-guards-at-any-cost` to instruct the check simply to work harder. Thus, pattern-guard checking would be enabled by default, but we would be protected from requiring 10GB of memory to compile a module. I was inspired by the fact that I would be tempted to enable pattern-guard checking by default in my own code, even if the check is non-performant. Then, in years' time, I would have a module that inexplicably takes forever to compile and forget to look here. The design above lets me have my cake and eat it too -- that is, to have my code checked but not worry about surprising compilation times. What do you think? Richard On Dec 12, 2015, at 1:05 PM, George Karachalias <george.karachalias(a)gmail.com> wrote: > > > On Sat, Dec 12, 2015 at 12:01 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > `f` will generate an empty uncovered set while g will generate: > > uncovered = > > { x |> { x ~ [], x ~ (_:_) } > > , x |> { x ~ (_:_), x ~ [] } } > > > > which is also semantically empty but this cannot be detected until we call the > > term oracle on it to see the inconsistency. > > > > So, why not call the term oracle more aggressively (at every node of the tree), to prune empty sets? It should not be hard to spot common cases; in what you show above it’s very easy. > > > Yes, we've been tempted to do this before but it didn't work. Since the sets can be really > big, we have relied on laziness a lot to save space and time. By calling the oracle more > often we will evaluate more eagerly parts of the sets which may lead to more space leaks. > > Additionally, in my reply for #11195 (https://ghc.haskell.org/trac/ghc/ticket/11195#comment:4) > you can find another example for which solving the constraints eagerly does not necessarily > improve the situation. Sometimes the sets are big and consistent. So checking eagerly does > not actually prune anything. I can see now that my `f` and `g` above were bad examples for this. > > Last but not least, the term oracle is not the most performant part of the checker. I would > certainly avoid calling it more often than we already do. > > Nevertheless, I do not want to drop the work we have done on pattern guards either so I > think that the flag solution is a very good and realistic option for now. If we really manage to > find a nice way to do better we can always update the code which will not be removed from > GHC. I will certainly keep thinking about it :) > > George > > -- > things you own end up owning you

1 0

User manual sub-sections
by Simon Peyton Jones 12 Dec '15

12 Dec '15

Ben, Austin, Could we see the sub-sub-sections of the user manual in the table of contents http://downloads.haskell.org/~ghc/master/users-guide/ The section titles are often very helpful. C.f. the old version https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html Simon

4 5

kind inference (#11203)
by Richard Eisenberg 12 Dec '15

12 Dec '15

Hi Simon and other devs, I struggled a bit today with some issues around kind inference that I wanted to write down. Here are some illuminating test cases, explained below: -- useful definition: data SameKind :: k -> k -> * 1. data T (a :: k1) x = MkT (S a ()) data S (b :: k2) y = MkS (T b ()) 2. data Q (a :: k1) (b :: k2) c = MkQ (SameKind a b) 3. data D1 = MkD1 (forall p (a :: k). p a -> Int) 4. data D2 a b = MkD2 (Proxy (a :: Maybe k)) | MkD3 (Proxy (b :: [k]) (1) should be accepted. But this is rather hard to arrange for, because T and S do not have CUSKs. Their kinds are generalized only after checking the mutually-recursive group. So, to accept this pair, we need to use SigTvs for k1 and k2, to allow them to unify with each other. (This works today.) (2) should be rejected. But it is currently accepted, because k1 and k2 are SigTvs, and so they unify with each other. (3) should be rejected. I have no idea where that k should be bound. Previously, the k was bound in the forall, but after the wildcards-refactor patch, that's no longer possible. (This is taken from test case ghci/scripts/T7873. HEAD accepts this definition, but produces a bogus tycon.) Note that this was accepted correctly before the wildcards-refactor. (4) should be accepted. This demonstrates that k can be introduced in constructors but scopes over the entire definition. The difference with case (3) is that (4) has type variables whose kinds mention k, whereas (3) does not. How should we arrange for all of this behavior? As stated in #11203, I think the use of SigTvs in PolyKinds is highly suspect. I have no good ideas here, though. In case (3), k ends up in the hsq_kvs (soon to be renamed to hsq_implicit) field of the HsQTyVars for D1. After kind inference, I've written a check to make sure k appears free in the kind of a tyvar. That works. The problem is that the check also snags cases (1) and (2): my check uses the name from the LHsQTyVars, and with SigTvs in the mix, (1) and (2) end up with kind variables with names different from the names in the LHsQTyVars. I'm sure there's some way to disentangle all of this, but I've given it a rest for now. This hit me in the fact that performance test case T9872d is like case (1), and the SigTvs threw my check off. But removing it caused problems elsewhere. I'd enjoy discussing next week. Thanks, Richard

1 1

A comment on Introspective-Haskell
by Levent Erkok 12 Dec '15

12 Dec '15

I just came across https://ghc.haskell.org/trac/ghc/ticket/11081, and the corresponding wiki-page: https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective I think this is a terrific idea. In the past, I've tried both TH and haskell-src-exts to do relatively simple things, but ended-up abandoning them due to the inherent complexity of source level haskell that had very little to do with what I really cared about. Being able to get your hands on Core at the regular Haskell level would truly simplify life, and I suspect would open the flood-gates for a lot of people to develop extremely cool/useful artifacts, making the GHC/Haskell experience even better. I hope this idea is taken further and sees the light-of-day. Richard: Did you have any further thoughts about possible plans? -Levent.

4 8