- ghc-devs - Haskell.org

Reading type families from interface files
by Jan Stolarek 23 Oct '14

23 Oct '14

Devs, Is there a plumbing for returning declarations (not instances) of type families from an interface file? Janek

2 4

Current description of Core?
by Sophie Taylor 23 Oct '14

23 Oct '14

Hi, Is the current description of Core still System FC_2 (described in https://www.seas.upenn.edu/~sweirich/papers/popl163af-weirich.pdf)?

6 9

Avoiding the hazards of orphan instances without dependency problems
by David Feuer 23 Oct '14

23 Oct '14

Orphan instances are bad. The standard approach to avoiding the orphan hazard is to always put an instance declaration in the module that declares the type or the one that declares the class. Unfortunately, this forces packages like lens to have an ungodly number of dependencies. Yesterday, I had a simple germ of an idea for solving this (fairly narrow) problem, at least in some cases: allow a programmer to declare where an instance declaration must be. I have no sense of sane syntax, but the rough idea is: {-# InstanceIn NamedModule [Context =>] C1 T1 [T2 ...] #-} This pragma would appear in a module declaring a class or type. The named module would not have to be available, either now or ever, but attempting to declare such an instance in any module *other* than the named one would be an error by default, with a flag -XAllowForbiddenInstancesAndInviteNasalDemons to turn it off. The optional context allows multiple such pragmas to appear in the type/class-declaring modules, to allow overlapping instances (all of them declared in advance).

7 17

RE: D202: Injective type families
by Simon Peyton Jones 22 Oct '14

22 Oct '14

Devs I now know how to use 'arc patch' to get a Phab ticket onto my disk. But if I edit the code, can I make a git commit and upload it back to D202? That would be akin to sharing a branch with (in this case Jan) the author. How do I do that? It is often more direct than making comments. Simon ________________________________________ From: noreply(a)phabricator.haskell.org [noreply(a)phabricator.haskell.org] Sent: 22 October 2014 14:18 To: Simon Peyton Jones Subject: [Differential] [Updated, 486 lines] D202: Injective type families jstolarek updated this revision to Diff 961. jstolarek added a comment. The implementation of parser and renamer is finished (subject to revisions of course). The parser recognizes injectivity declaration for closed and open type families and for associated types. Renamer checks whether the injectivity condition is well-formed. If it's not then it prints out informative (hopefully) error message. I've made the decission to require that type variables on the RHS of injectivity condition should be placed in exactly the same order as they were declared in type family head. Thanks to this the implementation of renaming is linear in the numer of type variables. Also, SynTyCon stores a list of Bools and so the functions are allowed to be injective only in some arguments. What remains to be done is: 1. type checking of injectivity (ie. whether the function declared as injective really is injective). 2. extending constraint solver with knowledge about injectivity REPOSITORY rGHC Glasgow Haskell Compiler CHANGES SINCE LAST UPDATE https://phabricator.haskell.org/D202?vs=960&id=961 BRANCH T6018-injective-type-families REVISION DETAIL https://phabricator.haskell.org/D202 AFFECTED FILES compiler/deSugar/DsMeta.hs compiler/hsSyn/Convert.lhs compiler/hsSyn/HsDecls.lhs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceSyn.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/parser/Parser.y.pp compiler/parser/RdrHsSyn.lhs compiler/prelude/TysPrim.lhs compiler/rename/RnSource.lhs compiler/rename/RnTypes.lhs compiler/typecheck/TcCanonical.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcInteract.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTypeNats.hs compiler/types/CoAxiom.lhs compiler/types/FamInstEnv.lhs compiler/types/TyCon.lhs compiler/vectorise/Vectorise/Type/Env.hs REPLY HANDLER ACTIONS Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, !unsubscribe. To: jstolarek, simonpj, goldfire, austin Cc: thomie, goldfire, simonmar, ezyang, carter, Mikolaj

2 1

Re: [commit: ghc] master: Reify data family instances correctly. (e319d6d)
by Joachim Breitner 22 Oct '14

22 Oct '14

Hi Richard, Travis is complaining about your commit: Actual stderr output differs from expected: --- ./th/T9692.stderr 2014-10-21 13:22:53.783212762 +0000 +++ ./th/T9692.comp.stderr 2014-10-21 13:52:36.314083513 +0000 @@ -1,2 +0,0 @@ -data family T9692.F (a_0 :: k_1) (b_2 :: k_3) :: * -data instance T9692.F GHC.Types.Int x_4 = T9692.FInt x_4 *** unexpected failure for T9692(normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/38604151/log.txt It maybe be due to a missing flushing of stdout; I added that line and will let you know if that was not it. Greetings, Joachim Greetings, Joachim Am Dienstag, den 21.10.2014, 13:21 +0000 schrieb git(a)git.haskell.org: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e319d6d2704edc2696f47409f85f4d4ce… > > >--------------------------------------------------------------- > > commit e319d6d2704edc2696f47409f85f4d4ce58a6cc4 > Author: Richard Eisenberg <eir(a)cis.upenn.edu> > Date: Mon Oct 20 15:36:57 2014 -0400 > > Reify data family instances correctly. > > Summary: > Fix #9692. > > The reifier didn't account for the possibility that data/newtype > instances are sometimes eta-reduced. It now eta-expands as necessary. > > Test Plan: th/T9692 > > Reviewers: simonpj, austin > > Subscribers: thomie, carter, ezyang, simonmar > > Differential Revision: https://phabricator.haskell.org/D355 > > > >--------------------------------------------------------------- > > e319d6d2704edc2696f47409f85f4d4ce58a6cc4 > compiler/typecheck/TcSplice.lhs | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/compiler/typecheck/TcSplice.lhs b/compiler/typecheck/TcSplice.lhs > index bb6af8c..e952a27 100644 > --- a/compiler/typecheck/TcSplice.lhs > +++ b/compiler/typecheck/TcSplice.lhs > @@ -1338,8 +1338,16 @@ reifyFamilyInstance (FamInst { fi_flavor = flavor > DataFamilyInst rep_tc -> > do { let tvs = tyConTyVars rep_tc > fam' = reifyName fam > + > + -- eta-expand lhs types, because sometimes data/newtype > + -- instances are eta-reduced; See Trac #9692 > + -- See Note [Eta reduction for data family axioms] > + -- in TcInstDcls > + (_rep_tc, rep_tc_args) = splitTyConApp rhs > + etad_tyvars = dropList rep_tc_args tvs > + eta_expanded_lhs = lhs `chkAppend` mkTyVarTys etad_tyvars > ; cons <- mapM (reifyDataCon (mkTyVarTys tvs)) (tyConDataCons rep_tc) > - ; th_tys <- reifyTypes lhs > + ; th_tys <- reifyTypes (filter (not . isKind) eta_expanded_lhs) > ; return (if isNewTyCon rep_tc > then TH.NewtypeInstD [] fam' th_tys (head cons) [] > else TH.DataInstD [] fam' th_tys cons []) } > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > -- 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

2 1

Re: Making GHCi awesomer?
by George Colpitts 22 Oct '14

22 Oct '14

Along the lines of making GHCi better it would be very nice if we could use SDL, OpenGL etc in GHCi. Is there a characterization of the libraries that we can't use in ghci? As you know this has been a problem for years. Is there an open bug about it? I know there was some hope that dynamic linking in 7.8.3 would fix this. What has been your experience? For some reason I get mail to ghc-devs but can't send mail to the mailing list. Thanks George On Sat, Oct 18, 2014 at 12:48 PM, Christopher Done <chrisdone(a)gmail.com> wrote: > Good evening, > > ... > > For years I’ve been using GHCi as a base and it’s been very reliable > for almost every project I’ve done (the only exceptions are things > like SDL and OpenGL, which are well known to be difficult to load in > GHCi, at least on Linux). I think we’ve built up > a good set of functionality > <https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode> > purely based on asking GHCi things and getting it to do things. > >

3 2

One-shot semantics in GHC event manager
by Ben Gamari 22 Oct '14

22 Oct '14

In ba2555ef and a6f52b19 one-shot semantics were added to event manager in `base`. If my understanding of this code is correct, in this mode the event manager will use only notify the user of the first event on a registered fd after which point the fd will need to be re-registered to get another notification. It appears this was done to optimize the common case of file I/O where only a single event is needed This change lead to a regression[1] in Bas van Dijk's usb library under GHC 7.8. usb's use of the event manager requires that all events on an fd are reported until the fd is registered or else hardware events are lost. I'm a bit perplexed as to why the change was made in the way that it was. Making one-shot a event-manager-wide attribute seems to add a fair bit of complexity to the subsystem while breaking backwards compatibility with library code. Going forward library authors now need to worry about whether the system event manager is one-shot or not. Not only is this platform dependent but it seems that there is no way for a user to determine which semantics the system event handler uses. Is there a reason why one-shot wasn't exported as a per-fd attribute instead of per-manager? Might it be possible to back out this change and instead add a variant of `registerFd` which exposes one-shot semantics? Cheers, - Ben [1] https://github.com/basvandijk/usb/issues/7

7 41

Warning on tabs by default (#9230) for GHC 7.10
by Austin Seipp 21 Oct '14

21 Oct '14

Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 5

GADTs in implementation of Template Haskell
by Richard Eisenberg 21 Oct '14

21 Oct '14

I'm doing a bunch of bug-fixes / improvements to Template Haskell. Two of these are to fix GHC bugs #8100 (add standalone-deriving support) and #9064 (add `default` method type signature support), both of which introduce new constructors for `Dec`. This got me thinking about `Dec` and the fact that different declaration forms are allowable in different contexts. (For example, datatype declarations are allowable only at the top level, and fixity declarations are allowable anywhere except in instance declarations.) How to encode these restrictions? With types, of course! Thus, I redesigned `Dec` to be a GADT. Having done so, I'm not 100% convinced that this is the right thing to do. I would love feedback on my full, concrete proposal available at https://ghc.haskell.org/trac/ghc/wiki/Design/TemplateHaskellGADTs Is this a change for the better or worse? Feel free either to comment on the wiki page or to this email. Thanks! Richard

2 1

GitHub pull requests
by Richard Eisenberg 21 Oct '14

21 Oct '14

I've just finished reading this: http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contain… For better or worse, I don't read reddit often enough to hold a conversation there, so I'll ask my question here: Is there a way we can turn GitHub pull requests into Phab code reviews? I'm thinking of something like this: - GitHub user ghc-newbie submits a pull request to github.com/ghc/ghc about feature X. - GitHub duly sends out notices to the watch list. - Some bot that is watching the repo receives the notification email that a pull request is submitted. - The bot then pulls down the pull request commit and creates a Phab code review from it. In a perfect world, the code review could be made to look like it comes from ghc-newbie, but I don't think this author-redirection is necessary, and ghc-newbie could be cited in an automatically-included comment. - The bot sends ghc-newbie an email with a link to the code review and something like this: Hi ghc-newbie, We've received your pull request on GitHub. Thanks! It's great that you've contributed. GHC, for a variety of well-considered reasons [1], uses a tool called Phabricator [2] -- not GitHub -- to process contributions. We have taken the liberty of posting your pull request to Phab for further review. You can see it here: <...> If you have modifications to make, please use our Phab workflow, documented in full here [3] and in brief here [4]. Thanks again, and we look forward to reviewing and hopefully merging your patch! GHC [1], [2], [3], [4]: <find appropriate destinations> - We GHC devs then carry on like we have been. If the patch is good, we can merge it without further input from ghc-newbie. If it's no good, and ghc-newbie doesn't get onto Phab, that's their loss. To naive me, this all seems possible -- and relatively easy -- to automate. (Naive = I've never done proper tool integration and am deeply grateful to anyone who actually makes things work.) Is this a good idea? Is this possible? Have I missed anything? Thanks for reading! Richard

12 25