October 2016 - ghc-devs

RE: Typeable meeting
by Simon Peyton Jones 06 Oct '16

06 Oct '16

Richard Ben and I concluded 1. Currently saturated (->) is treated differently to unsaturated (->), as witnessed by the special kinding rule for FunTy. The shortest path for TypeRep is to do the same: add TrFunTy. 1. Moreover we probably need FunCo for coercions; at the moment it's done with TyConAppCo, but that doesn't work with (->) :: * -> * -> *. Having FunCo would be (a) more efficient for a very common case, (b) deal with the kinding issue. 2. splitAppTy_maybe currently will split a FunTy even when it is not used at kind *. This is probably wrong. Maybe it should return Nothing in the non-* case. Ben is trying this out. 3. Orthogonally, one could imagine generalising the kind of prefix (->) to (->) :: forall r1 r2. TYPE r1 -> TYPE r2 -> Type LiftedPtrRep Then FunTy would become an abbreviation/optimisation, to avoid a plethora of runtime-rep args. And splitAppTy_maybe could succeed all the time on FunTy. Ben is trying this. 4. Under (3) at what kinds is ((->) ?? LiftedPtrRep (Ord Int) Char) called? If we continue to distinguish * from Constraint, we'd need to instantiate ?? with ConstraintRep, and define type Constraint = TYPE ConstraintRep Orthogonally, one might wonder about combining * and Constraint, but we don't yet know how to do that well. | -----Original Message----- | From: Richard Eisenberg [mailto:rae@cs.brynmawr.edu] | Sent: 06 October 2016 15:08 | To: Ben Gamari <ben(a)smart-cactus.org> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Typeable meeting | | Just seeing this now. (Please use my new address: rae(a)cs.brynmawr.edu) I | wasn't available yesterday at that time, anyway. | | Any conclusions reached? | | > On Oct 4, 2016, at 5:39 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: | > | > Simon Peyton Jones <simonpj(a)microsoft.com> writes: | > | >> Ben, and copying Richard who is far better equipped to respond than | me. | >> | >> I'm way behind the curve here. | >> | >> If "this is precisely what mkFunCo does" why not use mkFunCo? Why do | >> you want to "generalise the arrow operation"? | >> | > Perhaps I should have said "this is what mkFunCo is supposed to do". | > However, mkFunCo needs to be adjusted under the generalized (->) | > scheme, since the (->) tycon will gain two additional type arguments | > (corresponding to the RuntimeReps of the argument and result types). | > mkFunCo needs to fill these type arguments when constructing its | result. | > | >> I'm lost as to your goal and the reason why you need to wade through | this particular swamp. | >> | > There are a few reasons, | > | > * We want to provide a pattern to match against function types | > | > pattern TrFun :: TypeRep arg -> TypeRep res -> TypeRep (arg -> | > res) | > | > * T11120 currently fails on my branch as it contains a TypeRep of a | > promoted type containing an unboxed type. Namely, | > | > import Data.Typeable | > data CharHash = CharHash Char# | > main = print $ typeRep (Proxy :: Proxy 'CharHash) | > | > Note how 'CharHash has kind Char# -> Type. This kind occurs in one of | > the terms in `typeRep` needed in the above program, which currently | > results in core lint failures due to the restrictive kind of (->). | > For this reason (->) needs to be polymorphic over runtime | > representation. | > | > This issue is mentioned in ticket:11714#comment:1. | > | > * I believe there were a few other testcases that failed in similar | > ways to T11120. | > | > For what it's worth, the Type /~ Constraint issue that I'm currently | > fighting with in carrying out the (->) generalization is also the | > cause of another Typeable bug, #11715, so I think this is a worthwhile | > thing to sort out. | > | >> Also your text kind of stops... and then repeats itself. | >> | > Oh dear, I apologize for that. Clipboard malfunction. I've included a | > clean version below for reference. | > | >> We could talk at 2pm UK time tomorrow Weds. Richard would you be | free? | >> | > That would work for me. | > | > Cheers, | > | > - Ben | > | > | > | > | > # Background | > | > Consider what happens when we have the coercions, | > | > co1 :: (a ~ b) | > co2 :: (x ~ y) | > | > where | > | > a :: TYPE ra b :: TYPE rb | > x :: TYPE rx y :: TYPE ry | > | > and we want to construct, | > | > co :: (a -> x) ~ (b -> y) | > | > As I understand it this is precisely what Coercion.mkFunCo does. | > Specifically, co should be a TyConAppCo of (->) applied to co1, co2, | > and coercions showing the equalities ra~rx and rb~ry, | > | > (->) (co_ax :: ra ~ rx) (co_by :: rb ~ ry) co1 co2 | > | > Actually implementing mkFunCo to this specification seems to be not | > too difficult, | > | > -- | Build a function 'Coercion' from two other 'Coercion's. That | is, | > -- given @co1 :: a ~ b@ and @co2 :: x ~ y@ produce @co :: (a -> x) | > ~ (b -> y)@. | > mkFunCo :: Role -> Coercion -> Coercion -> Coercion | > mkFunCo r co1 co2 = | > mkTyConAppCo r funTyCon | > [ mkRuntimeRepCo r co1 -- ra ~ rx where a :: TYPE ra, x :: TYPE | > rx | > , mkRuntimeRepCo r co2 -- rb ~ ry where b :: TYPE rb, y :: TYPE | > ry | > , co1 -- a ~ x | > , co2 -- b ~ y | > ] | > | > -- | For a constraint @co :: (a :: TYPE rep1) ~ (b :: TYPE rep2)@ | > produce | > -- @co' :: rep1 ~ rep2@. | > mkRuntimeRepCo :: Role -> Coercion -> Coercion | > mkRuntimeRepCo r co = mkNthCoRole r 0 $ mkKindCo co | > | Just (tycon, [co]) <- splitTyConAppCo_maybe $ mkKindCo co | > = co | > | otherwise | > = pprPanic "mkRuntimeRepCo: Non-TYPE" (ppr co) | > | > So far, so good (hopefully). | > | > # The Problem | > | > Consider what happens when one of the types is, e.g., HasCallStack. | > For the sake of argument let's say | > | > co1 = <HasCallStack>_R | > co2 = <Int>_R | > | > Recall that HasCallStack is, | > | > type HasCallStack = ((?callStack :: CallStack) :: Constraint) | > | > The problem arises when we attempt to evaluate | > | > mkFunCo r co1 co2 | > | > which will look at the kind coercion of co1, | > | > mkKindCo co1 === <Constraint>_R | > | > and then attempt to splitTyConAppCo it, under the assumption that the | > kind coercion is an application of TYPE, from which we can extract the | > RuntimeRep coercion. Instead we find a nullary TyConAppCo of | > Constraint; things then blow up. | > | > This is the problem. | > | > Ultimately it seems all of this is due to the fact that we play it | > fast- and-loose with Type and Constraint in Core (#11715), especially | > with implicit parameters. I worry that resolving this is more than I | > have time to chew on before 8.2.

3 6

Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
by Carter Schonwald 05 Oct '16

05 Oct '16

In writing the following huge wall of text, I had and idea that I think many folks would find palatable: What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple! What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever! My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period. Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both. My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup. I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that! I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against ) On Saturday, September 24, 2016, Brandon Allbery <allbery.b(a)gmail.com> wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > chak(a)justtesting.org > <javascript:_e(%7B%7D,'cvml','chak(a)justtesting.org');>> wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b(a)gmail.com');> > ballbery(a)sinenomine.net > <javascript:_e(%7B%7D,'cvml','ballbery(a)sinenomine.net');> > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

15 31

Status of Harbormaster
by Ben Gamari 04 Oct '16

04 Oct '16

Hello everyone, Over the last few weeks I have been gradually pushing away at increasing our Harbormaster coverage. I'm happy to report that Harbormaster should now test commits on, * x86_64 Ubuntu Linux * x86_64 Mac OS X Sierra * x86_64 Windows (although the bugs are still being worked out here) Differentials are tested on, * x86_64 Ubuntu Linux * x86_64 Windows For those of you following along at home I've roughly documented the configuration on the Phabricator Wiki [1]. One open question is whether we want to enable Differential building on the OS X box. The security implications of allowing essentially anonymous users to build and run untrusted code in our own CI environment are already quite sticky; to enable Differential building on the OS X box would mean that we would be running untrusted code on someone else's hardware, which seems like it may be a step too far. It would be nice to find a way to extend Differential builds to other platforms in the future, however, so we can ensure that we catch bad patches before they even make it to the tree. It's a bit unclear how far we should extend test coverage. In the future I think I will at very least add an i386 Ubuntu environment, but we could go farther still. For instance these platforms immediately come to mind, * x86_64 FreeBSD * x86_64 Solaris * ARM Linux (although this could be quite tricky given the speed of these machines) * AArch64 Linux There is certainly a maintenance and complexity tradeoff that comes with extending our coverage like this, however, so it's quite unclear where the right compromise lies. I'd love to hear what you think. Happy hacking, - Ben [1] https://phabricator.haskell.org/w/ghc_harbormaster/

4 3

SafeHaskell vs TemplateHaskell
by Erik de Castro Lopo 04 Oct '16

04 Oct '16

Hi all, I tried to fix trac ticket #12511 (template-haskell's Language.Haskell.Syntax module should be Trustworthy) but in doing so I began to think this is actually a bad idea. Specifically, I suspect its actually possible to craft something using TH that bypasses the guarantees that Safe is supposed to ensure. Comments? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1

GHC 8.0.2 status
by Ben Gamari 04 Oct '16

04 Oct '16

Hello everyone, The week before ICFP I was able to get the ghc-8.0 branch ready for an 8.0.2 release, which I intended to cut this week. In the intervening time an additional rather serious issue was reported affected Mac OS X Sierra (#12479). Since this issue affects the usability of GHC on the new OS X release, we'll be deferring the 8.0.2 release until it has been resolved. While there appears to be an actionable path forward on this ticket, we will need someone with an affected machine and an understanding of GHC's use of dynamic linking to step up to implement. Otherwise it looks like the release will be delayed at least until October 9, when darchon has time to have a look. Sorry to be the bearer of bad news! Cheers, - Ben

4 3

Patterns & Quality Attributes Research
by Michael Skeen 03 Oct '16

03 Oct '16

Dear Haskell Compiler Community, We are doing undergraduate research on software architecture patterns and quality attributes for Utah Valley University. We recently analyzed the work published on Haskell Compiler in the Architecture of Open Source Applications <http://aosabook.org/en/index.html> (AOSA) and referenced it in a paper we presented at the 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), as attached. As a part of our continuing research we wish to validate our architectural analysis for Haskell Compiler with the current developers. We would like to know if we are missing any patterns or quality attributes that may have been included in Haskell Compiler, or if there are any we listed that aren’t used. Any additional comment on these topics you might have would also, of course, be welcome. We believe we found the following software architectural patterns in this application: Pattern Name Is This Found in the Architecture? (yes / no / don’t know) Comments (optional) Interpreter Layers Pipes & Filters Plugin Rule-Based System Other? We also identified the following quality attributes: Attribute Name Is This Found in the Architecture? Comments (optional) Scalability Usability Performance Portability Reliability Portability Maintainability Testability Modularity Robustness Other? For your convenience, we have a complete list below of the patterns and quality attributes we referred to when conducting our research. To clarify, we are specifically studying architectural patterns, rather than design patterns such as the GoF patterns. Architectural Patterns Considered Quality Attributes Considered Active Repository Scalability Batch Usability Blackboard Extensibility Broker Performance Client Server Portability Event System Flexibility Explicit Invocation Reliability Implicit Invocation Maintainability Indirection Layer Security Interceptor Testability Interpreter Capacity Layers Cost Master and Commander Legality Microkernel Modularity Model View Controller Robustness Peer to Peer Pipes and Filters Plugin Presentation Abstraction Control Publish Subscribe Reflection Rule-Based System Shared Repository Simple Repository State Based Virtual Machine Please respond by October 17, if possible. Thank you for considering our request, and for your continued work on Haskell Compiler. Sincerely, Erich Gubler, Danielle Skinner, Brandon Leishman, Michael Skeen, Neil Harrison, Ph.D. (advisor) Reference: Neil B. Harrison, Erich Gubler, Danielle Skinner, "Software Architecture Pattern Morphology in Open-Source Systems",WICSA, 2016, 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA) 2016, pp. 91-98, doi:10.1109/WICSA.2016.8

1 0

Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 03 Oct '16

03 Oct '16

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial.... if it works, it's really a fluke. We don't really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter... if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I'm on a plane, so I'm going to at least start with an email. Simon

9 15

Re: How, precisely, can we improve?
by Moritz Angermann 01 Oct '16

01 Oct '16

Richard, thank you for trying to give this some technical basis. As someone who as contributed some tiny bugfixes to ghc, I found the process a bit cumbersome, yet manageable[1]. I’d however like to propose some concrete changes, and please excuse if these have been discussed and found to not be actionable. What I’d really like to see improved is the “multiple (web)services, multiple accounts” issue solved. As it is right now I need to have a github account (ghc-proposals, soon tiny PR against ghc), a trac account (for the wiki and issue tracker; which never seems to remember me), a phabricator account[2], likely a stack overflow account for questions and answers. On top of that I also need to be on a large set of mailing lists if I want to not miss anything, and an irc client and twitter client to tap into the most recent discussions. And there’s another wiki on haskell.org for which I would need to sign up and get an approved account. I’d like to see the following: 1. Unify the issue tracker and code review into phabricator. Hence *if* I want to contribute to the ghc codebase, I essentially only need a phabricator account[3]. And a simple one page website on haskell.org that runs me through the “Contributing to GHC” as in: > GHC Development is facilitated through phabricator. > > Please go to https://phabricator.haskell.org[4] and > create an account. > > If you want to report a bug, please file a bugreport through > the “Maniphest” module, you can find on the left. > > If you are looking for something to contribute, and browse the > Open Tasks at https://phabricator.haskell.org/maniphest/query/open/[5] > > Clone the GHC tree and build it > [ clone and build instructions here; note about stage2 pinning to reduce compile times and other > build system features ] > > Hack to your hearts content on GHC (you might get some quick responses > regarding ghc’s internals at irc://irc.freenode.net/ghc, as well as in > the ghc commentary at …[6], or the ghc-dev mailing list for which you > can sign up at ...) > > Validate your build [ plus instructions how to do so, and how to run > performance measurements on the changed ghc; if one is interested in > that as well ] > > Upload your patch to GHC using the arc command line tool. You will have > to set up your token during the first use, just follow the instructions. > > To upload your patch, commit your local changes; and run > $ arc diff origin/master > > arc will run a few linters against your diff, and provide you with a form > to fill in all the details regarding your patch. This form is usually > prepopulated with the commit messages from your local commits. > > During the review process you might have to update your diff. To do so > you can rebase your changes against the most recent master and/or add > additional commits to it; once you are done updating your patch, run > $ arc diff --update > > Once your diff has been accepted, someone with commit rights with “land” your > diff into the official ghc tree. And have this prominently liked from https://www.haskell.org/ under “Contributing” 2. Move the Wiki someplace else. I don’t know if the wiki in phabricator is any good, I’ve never used it. However, finding something in the ghc wiki has been more hit and miss for me than anything else. The built in search almost never reveals what I’m looking for, and resorting to a search engine only sometimes helps me find what I’m looking for. (This might totally be my fault). 3. Reduce the number of Mailing lists. I’m supposedly not on the haskell ml; so I missed https://mail.haskell.org/pipermail/haskell/2016-September/024995.html, and only saw it due to https://twitter.com/ezyang/status/780134457101516800. Are our MLs really that high volume that we need so many? 4. I like the idea of trivial pull requests to be accepted on GH as well. And I don’t see it as a big hurdle to ask someone to please be so kind and submit the patch through phabricator if it’s more involved with a link to https://www.haskell.org/contributing (see above). In conclusion I’d like to propose to reduce the fragmentation of tooling, and accept the status quo of what open source development seems looks like to many (github for code, stackoverflow questions (and documentation soon?)) as much as we can. Cheers, Moritz — [1]: I didn’t understand phabriactor and arc in the beginning, however today I appreciate the process phabricator and arc offer a lot! (Over PRs) [2]: for which you can actually use your bitbucket, github, twitter, … account. [3]: I will also need some access to the staging area, if I want to use that feature. [4]: Can we have http://phabricator.haskell.org redirect to https://phabricator.haskell.org? Instead of having both? [5]: I guess one could create some Trivial, Easy, Medium and Hard queries. [6]: This is currently scattered across the trac wiki. > On Sep 26, 2016, at 9:27 AM, Richard Eisenberg <rae(a)cs.brynmawr.edu> wrote: > > Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. > > I'd like to move the conversation forward -- and I'd like to do so on a technical basis. > > So, I ask: > How, precisely, can we improve? > > I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. > > As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. > > "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) > > "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) > > "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html > > "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. > > "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. > > Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html) I look forward to a similarly technical, respectful discussion on our contribution process. > > Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

16 39

[GHC Proposal] Allow use of TypeApplications in SPECIALISE pragmas
by Ben Gamari 01 Oct '16

01 Oct '16

Hello everyone, I just opened Pull Request #15 [1] against the ghc-proposals repository, describing a propsed extension to the syntax of the SPECIALISE pragma, allowing significantly more concise usage. Please give it a read through and leave your comments. Thanks! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/15

1 0

[GHC Proposal] Type-indexed Typeable
by Ben Gamari 01 Oct '16

01 Oct '16

Hello everyone, I just opened Pull Request #16 [1] against the ghc-proposals repository, describing the new Type-indexed Typeable machinery that we would like to introduce with GHC 8.2. Please give it a read through and leave your comments. Thanks! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/16

1 0