From ezyang at mit.edu Mon Aug 1 21:03:35 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 01 Aug 2016 14:03:35 -0700 Subject: FINAL CALL FOR TALKS (Aug 8 deadline): Haskell Implementors Workshop 2016, Sep 24, Nara Message-ID: <1470085297-sup-7909@sabre> Deadline is in a week! Submit your talks! Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers --- End forwarded message --- From ryan.gl.scott at gmail.com Tue Aug 2 22:59:17 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 2 Aug 2016 18:59:17 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Thanks for the feedback, everyone! I've typed up the developments so far in the DerivingStrategies Haskell wiki page [1]. Here's what seems to be the consensus: * The syntax in which actual keywords are used to designate deriving strategies was the clear favorite. * In particular, a slight edge goes to the form in which multiple deriving clauses can be placed after a datatype, and each `deriving` clause has its own (optional) strategy keyword, as opposed to putting the keyword directly in front of the derived type. * The `builtin` keyword was poorly received. There isn't a obvious candidate to replace it, and several of us like the word `bespoke`, so it looks like `bespoke` will be the replacement. (If someone ends up complaining about it, we've got several other choices.) Any other questions or comments? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones wrote: > I'm not following all the details here, and I do not feel strongly about syntax; but I do hope that you'll update the wiki page to reflect the discussion. > > Thanks > > Simon > > -----Original Message----- > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Scott > Sent: 18 July 2016 15:00 > To: Richard Eisenberg > Cc: Andres Loeh ; GHC developers > Subject: Re: Request for feedback: deriving strategies syntax > > Andres, > >> The objects probably shouldn't be type synonyms, but they could be >> special datatypes or type families, perhaps. > > I considered that - we already have some special datatypes, type families, and type classes currently. However, neither datatypes nor type families are allowed to appear as the outermost type in an instance declaration (unless we bake in a very prominent exception to this rule), and if we imbued type classes with this magic, one might think that "deriving (GND Eq)" means we're deriving an instance for the magical GND class, not Eq. So those approaches don't sound satisfying to me on a cursory examination. > > Richard, > >> The one idea I can suggest in this space (somewhat tongue-in-cheek, >> but feel free to take it seriously) is `bespoke` > > It might be a tongue-in-cheek suggestion, but I _really_ like it. It captures the intended semantics better than any other previous suggestion, I think. And we're already going to be appropriating a new keyword with "anyclass", so why not take "bespoke" as well? :) > > Please stop me if I've slipped into madness here. > >> I thought about verbosity here, and it's not clear which one is more verbose. For example, I frequently define a new newtype and then wish to use GND to derive a whole host of instances. In this case (is it common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter than putting newtype on each class name. > > That's a good point. Another thing to consider is that I suspect in 90% of the time, users are only going to be reaching for -XDerivingStrategies in the scenario when they enable both -XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when they want to derive instances for newtypes, and as you said, you typically derive several instances at a time when defining newtypes. > Therefore, it seems less noisy to factor out the deriving strategy names so that readers can tell at a glance which batch of instances are newtype-derived and which are anyclass-derived, instead of having to read a keyword before every single type. > > Plus, on a superficial level, I like keeping the deriving strategy name outside of the parentheses. I think it makes clear that these keywords aren't modifying the type we're deriving, only the means by which we're deriving it. Of course, you may feel differently than I do, so please speak up if you disagree! > > > Ryan S. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07cede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKUdDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d From omeragacan at gmail.com Wed Aug 3 10:10:01 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 3 Aug 2016 10:10:01 +0000 Subject: A function with absent demand on syntactically used argument? Message-ID: I'm reading the code in WwLib that generates worker functions and I'm confused about absent lets. Can anyone give an example function that has absent demand on its argument even though the argument is syntactically used in the body? I think we should add some examples to `Note [Absent errors]` in WwLib.hs. One example came to my mind was something like f x = ... undefined x ... I'm guessing that if we were to generate a worker for this, we'd need to generate an absent let for x in the worker function. But "undefined" has a weird (polymorphic over both function and non-function types) type and I don't know what's the demand signature of it (maybe we should document this too), so I'm not sure. From mail at joachim-breitner.de Wed Aug 3 11:54:46 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Aug 2016 07:54:46 -0400 Subject: A function with absent demand on syntactically used argument? In-Reply-To: References: Message-ID: <1470225286.3268.2.camel@joachim-breitner.de> Am Mittwoch, den 03.08.2016, 10:10 +0000 schrieb Ömer Sinan Ağacan: > I'm reading the code in WwLib that generates worker functions and I'm confused > about absent lets. Can anyone give an example function that has absent demand > > its argument even though the argument is syntactically used in the body? here is a simple example: printFst :: (a,b) -> IO () -- printFst (a,b) = print a callPrintFirst :: b -> IO () -- callPrintFirst b = printFst ("see it?", b) > > I think we should add some examples to `Note [Absent errors]` in WwLib.hs. *shrug* Not sure if it is worth it. > One example came to my mind was something like > >     f x = ... undefined x ... > > I'm guessing that if we were to generate a worker for this, we'd need to > generate an absent let for x in the worker function. But "undefined" has a > weird (polymorphic over both function and non-function types) type and I don't > know what's the demand signature of it (maybe we should document this too), so > I'm not sure. undefined as signature "b", indicating „even if given no arguments, I will bottom out“. The demand analyzer treats that as „b“ if necessary, i.e. if undefined is applied to an argument. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ryan.gl.scott at gmail.com Wed Aug 3 17:23:43 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 3 Aug 2016 13:23:43 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <0B260DAF-4658-4393-BF85-980BE65A28B3@cis.upenn.edu> References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> <0B260DAF-4658-4393-BF85-980BE65A28B3@cis.upenn.edu> Message-ID: That is a good question. Weirdly enough, the current behavior for how a deriving strategy is resolved (without explicit keywords) isn't really documented anywhere, so I attempted to figure out what GHC currently does and documented it here [1]. I'll reproduce the algorithm (including deriving strategies) below: 1. Look for a deriving strategy. If one is present, use that. 2. (a) If deriving an `Eq`, `Ord`, `Ix`, or `Bounded` instance for a newtype, use the `GeneralizedNewtypeDeriving` strategy (even if the language extension isn't enabled). (b) If deriving a `Read`, `Show`, `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, or `Lift` instance for a newtype, go to step 3. (c) Otherwise, if deriving a "standard derivable class" (e.g., `Eq`, `Ord`, `Generic`, etc.) instance for a newtype, and `-XGeneralizedNewtypeDeriving` is enabled, derive the class using the `GeneralizedNewtypeDeriving` strategy. (d) Otherwise, if deriving an instance for a newtype and both `-XGeneralizedNewtypeDeriving` and `-XDeriveAnyClass` are enabled, default to `DeriveAnyClass`, but emit a warning stating the ambiguity. (e) Otherwise, if deriving an instance for a newtype, the datatype and typeclass can be successfully used with `GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` is enabled, do so. 3. (a) If deriving a "standard derivable class" (e.g., `Eq`, `Ord`, `Generic`, etc.) and the corresponding language extension is enabled (if necessary), do so. If the language extension is not enabled, throw an error. (b) Otherwise, if `-XDeriveAnyClass` is enabled, use that. (c) Otherwise, throw an error. This is quite ugly, but to my knowledge this is currently what GHC does (excluding 2(c), which is a bit that fixes a bug reported in Trac #10598 [2]), so there shouldn't be any change in behavior from before. This is another good reason to want deriving strategies: trying to remember all of that is nearly impossible! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Thederivingstrategyresolutionalgorithm [2] https://ghc.haskell.org/trac/ghc/ticket/10598 On Wed, Aug 3, 2016 at 11:53 AM, Richard Eisenberg wrote: > >> On Aug 2, 2016, at 6:59 PM, Ryan Scott wrote: >> Any other questions or comments? >> > > Yes, a question: What is the behavior if no keyword is given? Any change here from the status quo is quite dangerous from a backward-compatibility standpoint, but I wonder if we could start issuing warnings/errors in a few years. > > Richard > From _deepfire at feelingofgreen.ru Wed Aug 3 23:15:39 2016 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Thu, 04 Aug 2016 02:15:39 +0300 Subject: Request for feedback: deriving strategies syntax In-Reply-To: (sfid-20160803_220102_002990_86DBABC7) (Ryan Scott's message of "Wed, 3 Aug 2016 13:23:43 -0400") References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> <0B260DAF-4658-4393-BF85-980BE65A28B3@cis.upenn.edu> Message-ID: <87y44dwijo.fsf@feelingofgreen.ru> Ryan Scott writes: > That is a good question. Weirdly enough, the current behavior for how > a deriving strategy is resolved (without explicit keywords) isn't > really documented anywhere, so I attempted to figure out what GHC > currently does and documented it here [1]. I'll reproduce the > algorithm (including deriving strategies) below: How much of this derivation machinery could NOT be implemented by means of some kind of a (hypothetical) type-backed metaprogramming facility? The beauty of an open implementation[1] allowed by such a thing is that: 1. uniformity of definition of the desugaring transformation would have followed, and from that: - the "bespoke" derivation mechanism will suddenly become explainable in a language shared by all derivation mechanisms: - the separate derivation strategies as separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - the combined strategy as an overarching macro tranformation - therefore, users would have been empowered to easily provide derivation mechanisms of the same power as "bespoke", plugging into the aforementioned scheme 2. because of above, we get a starting point from which we can evolve something that can be meaningfully standartized, without a feeling of shame or guilt -- we now have a language describing the problem domain, that can be un-tied from a particular implementation 3. in-editor macroexpansion is a proven, working concept in the realm of Proper Metaprogramming (viz. Common Lisp etc.), and it would basically eliminate guesswork from user workflows ..or is this all a violent pipe dream? -- с уважениeм / respectfully, Косырев Сергей -- 1. The concept of an "open implementation" comes from a paper by Kiczales and Paepcke. Although the concept comes from the context of metaobject protocols the core idea seems universally applicable -- careful exposure and reification of implementation machinery can be beneficial. From _deepfire at feelingofgreen.ru Wed Aug 3 23:37:19 2016 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Thu, 04 Aug 2016 02:37:19 +0300 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <87y44dwijo.fsf@feelingofgreen.ru> (sfid-20160804_035244_026070_36332228) (Kosyrev Serge's message of "Thu, 04 Aug 2016 02:15:39 +0300") References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> <0B260DAF-4658-4393-BF85-980BE65A28B3@cis.upenn.edu> <87y44dwijo.fsf@feelingofgreen.ru> Message-ID: <87shulwhjk.fsf@feelingofgreen.ru> Kosyrev Serge <_deepfire at feelingofgreen.ru> writes: > How much of this derivation machinery could NOT be implemented by means of > some kind of a (hypothetical) type-backed metaprogramming facility? > > The beauty of an open implementation[1] allowed by such a thing is that: I apologize for the unfortunate metacircular logic in the below passage: > 1. uniformity of definition of the desugaring transformation > would have followed, and from that: > > - the "bespoke" derivation mechanism will suddenly become > explainable in a language shared by all derivation mechanisms: > > - the separate derivation strategies as separate, named macro > transformations, using a common library of type-level and other > tools -- mostly those already in existence > - the combined strategy as an overarching macro tranformation It should instead read as: 1. uniformity of expression of the desugaring transformation would have followed, in the following way: - the overall derivation mechanism is to become expressible through the following composition: - the separate derivation strategies are to become separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - this aforementioned common library is explicitly required to be sufficiently powerful to able to express the "bespoke" derivation mechanism - the combined strategy as an overarching macro tranformation The rest stands as is: > 2. because of above, we get a starting point from which we can > evolve something that can be meaningfully standartized, without a > feeling of shame or guilt -- we now have a language describing the > problem domain, that can be un-tied from a particular implementation > > 3. in-editor macroexpansion is a proven, working concept in the realm > of Proper Metaprogramming (viz. Common Lisp etc.), and it would > basically eliminate guesswork from user workflows > > ..or is this all a violent pipe dream? -- с уважениeм / respectfully, Косырев Сергей From ekmett at gmail.com Thu Aug 4 00:26:48 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 3 Aug 2016 20:26:48 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <4E7A309C-87E2-4947-A191-CDCA391C8E83@cis.upenn.edu> References: <4E7A309C-87E2-4947-A191-CDCA391C8E83@cis.upenn.edu> Message-ID: It has the benefit that nothing lowercase would ever derive in that position so it is a strict extension of the current syntax. So even it builtin or whatever is a conditional keyword like qualified and as, I don't see any issues with it. 'bespoke' does make me smile, though. =) -Edward On Sun, Jul 17, 2016 at 10:24 PM, Richard Eisenberg wrote: > Of the three options from Ryan's first email in this thread, only the > third is palatable to me (with the separate `deriving` clauses). > > I would like to mention that I don't see any real obstacles to something > like > > > newtype ... > > deriving (Eq, default ToJSON, builtin Ord, newtype Monoid) > > That is, one `deriving` clause where each element is optionally prefixed > with a keyword. On the ticket (#10598), it is suggested that parsing these > would be hard. I agree that parsing these would be annoying, but I do not > think that they are actually ambiguous. Avoiding a few hours of pain in the > parser should not be our motivation for choosing a syntax we will all live > with for years. For `default` and `newtype`, parsing is actually easy. If > we want to keep the `builtin` pseudo-keyword, we could always parse as a > type and then have some non-parser code examine the resulting AST and sort > it out. (This is done in several other dark corners of the parser already.) > > Separately, I'm not enamored of the `builtin` keyword. The one idea I can > suggest in this space (somewhat tongue-in-cheek, but feel free to take it > seriously) is `bespoke` -- after all, each "builtin" instance must be > generated by code written specifically for that class, which fits the > English definition of bespoke nicely. "Which deriving mechanism do want?" > "The bespoke one, please." And then GHC can boast that it has the classiest > keyword of any programming language. :) > > Richard > > On Jul 16, 2016, at 10:02 PM, Ryan Scott wrote: > > > I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do > > not have fine-grained control over which strategy to use when deriving > > an instance, especially when multiple extensions like > > -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled > > simultaneously. I have a working patch up at [2] which would fix the > > issue, but there's still a lingering question of what the right syntax > > is to use here. I want to make sure I get this right, so I'm > > requesting input from the community. > > > > To condense the conversation in [1], there are three means by which > > you can derive an instance in GHC today: > > > > 1. -XGeneralizedNewtypeDeriving > > 2. -XDeriveAnyClass > > 3. GHC's builtin algorithms (which are used for deriving Eq, Show, > > Functor, Generic, Data, etc.) > > > > The problem is that it's sometimes hard to know which of the three > > will kick in when you say `deriving C`. To resolve this ambiguity, I > > want to introduce the -XDerivingStrategies extension, where a user can > > explicitly request which of the above ways to derive an instance. > > > > Here are some of the previously proposed syntaxes for this feature, > > with their perceived pros and cons: > > > > ----- Pragmas > > * Examples: > > - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-} > > Ord, {-# DAC #-} Read, Show) > > - deriving {-# BUILTIN #-} instance Functor T > > * Pros: > > - Backwards compatible > > - Requires no changes to Template Haskell > > * Cons: > > - Unlike other pragmas, these ones can affect the semantics of a > program > > ----- Type synonyms > > * Examples: > > - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show) > > - deriving instance Builtin (Functor T) > > * Pros: > > - Requires no Template Haskell or parser changes, just some > > magic in the typechecker > > - Backwards compatible (back to GHC 7.6) > > * Cons: > > - Some developers objected to the idea of imbuing type synonyms > > with magical properties > > ----- Multiple deriving clauses, plus new keywords > > * Examples: > > - newtype T a = T a > > deriving Show > > deriving builtin instance (Eq, Foldable) > > deriving newtype instance Ord > > deriving anyclass instance Read > > - deriving builtin instance Functor T > > * Pros: > > - Doesn't suffer from the same semantic issues as the other > suggestions > > - (Arguably) the most straightforward-looking syntax > > * Cons: > > - Requires breaking changes to Template Haskell > > - Changes the parser and syntax significantly > > > > Several GHC devs objected to the first two of the above suggestions in > > [1], so I chose to implement the "Multiple deriving clauses, plus new > > keywords" option in [2]. However, I'd appreciate further discussion on > > the above options, which one you prefer, and if you have other > > suggestions for syntax to use. > > > > Ryan S. > > ----- > > [1] https://ghc.haskell.org/trac/ghc/ticket/10598 > > [2] https://phabricator.haskell.org/D2280 > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Aug 4 00:50:06 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 3 Aug 2016 20:50:06 -0400 Subject: Request for feedback: deriving strategies syntax Message-ID: > How much of this derivation machinery could NOT be implemented by means of > some kind of a (hypothetical) type-backed metaprogramming facility? I think this would be a wonderful thing to have. Matthew Pickering (cc'd) has expressed a desire to have all the logic for the `bespoke` deriving strategies compartmentalized into a library that could easily be expanded on in the future to support more typeclasses in base. (Bifunctor, anyone?) Unfortunately, each of the major players in today's Haskell metaprogramming scene that I'm aware of have some downfalls that make them unsuitable as `deriving` replacements: * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. The way I see it, the whole `deriving` business as it currently stands today is a somewhat-grotesque-but-darn-useful hack that gets around the lack of a truly nice metaprogramming facility in Haskell. I'm holding out hope that the work in https://github.com/shayan-najd/NativeMetaprogramming makes things nicer soon, and then we can revisit this idea. Until then, -XDerivingStrategies provides a way to contain some of the madness of `deriving` after having many features tacked onto it in recent GHC releases. Ryan S. From rae at cs.brynmawr.edu Thu Aug 4 02:52:00 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 3 Aug 2016 22:52:00 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: > On Aug 3, 2016, at 8:50 PM, Ryan Scott wrote: > > * Template Haskell: Not portable. Staging issues make it hard to use > as a drop-in replacement for the `deriving` keyword I do not understand "not portable" here. Do you mean that some architectures don't support TH? What staging issues? I'm imagining here having `deriving Blah` be surface syntax that desugars into some TH splice. You keep the nice user-facing syntax, but make the deriving mechanism itself specified in TH code. It's an interesting idea, but one probably best tackled after the current proposal. Richard From allbery.b at gmail.com Thu Aug 4 03:12:07 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 3 Aug 2016 23:12:07 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: On Wed, Aug 3, 2016 at 10:52 PM, Richard Eisenberg wrote: > I do not understand "not portable" here. Do you mean that some > architectures don't support TH? Sounded to me like they're targeting the standards path, which means not tying it to something that's fairly inherently GHC specific. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Thu Aug 4 05:20:16 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 4 Aug 2016 07:20:16 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: On 2016-08-04 02:50, Ryan Scott wrote: > I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Are there any papers on this? (Or even just blog posts and such.) Sounds really intriguing, but obvious searches didn't find anything. Regards, From matthewtpickering at gmail.com Thu Aug 4 09:50:39 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 4 Aug 2016 10:50:39 +0100 Subject: Inlining Wiki Page Message-ID: Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a newcomer to start working on GHC. The inliner is quite well contained, there are lots of open tickets with well-specified aims and lots of investigatory work to be done. So the purpose of this email is: 1. Please tag any tickets relevant to inlining/specialisation with "Inlining" 2. Any newcomers keen to get involved should read the wiki page and see if they can tackle one of the tickets there. Matt From matthewtpickering at gmail.com Thu Aug 4 10:44:23 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 4 Aug 2016 11:44:23 +0100 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: I made a ticket to track this issue. https://ghc.haskell.org/trac/ghc/ticket/12457 Matt On Thu, Aug 4, 2016 at 6:20 AM, Bardur Arantsson wrote: > On 2016-08-04 02:50, Ryan Scott wrote: >> I'm >> holding out hope that the work in >> https://github.com/shayan-najd/NativeMetaprogramming makes things >> nicer soon, and then we can revisit this idea. > > Are there any papers on this? (Or even just blog posts and such.) Sounds > really intriguing, but obvious searches didn't find anything. > > Regards, > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Thu Aug 4 13:08:29 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Aug 2016 09:08:29 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: > I do not understand "not portable" here. Do you mean that some architectures don't support TH? Template Haskell doesn't play nicely with cross compilation [1] or stage-1 compilers, so Template Haskell is simply a non-starter for a lot of uses. It's why the GHC codebase and boot libraries largely don't use the -XTemplateHaskell extension (aside from the test suite, of course). > What staging issues? > > I'm imagining here having `deriving Blah` be surface syntax that desugars into some TH splice. You keep the nice user-facing syntax, but make the deriving mechanism itself specified in TH code. That won't currently work with the way TH stages its splices. For example, the following code: {-# LANGUAGE PackageImports, TemplateHaskell #-} import "deriving-compat" Data.Eq.Deriving bar :: Bar bar = Bar data Foo = Foo $(deriveEq ''Foo) data Bar = Bar $(deriveEq ''Bar) will fail to compile because of the staging restrictions on Template Haskell splices, whereas replacing the splices with `deriving Eq` would make it compile. > It's an interesting idea, but one probably best tackled after the current proposal. Completely agreed. :) Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/CrossCompilation From ryan.gl.scott at gmail.com Thu Aug 4 13:12:05 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 4 Aug 2016 09:12:05 -0400 Subject: Request for feedback: deriving strategies syntax Message-ID: Sorry for not including the full context on that link. It's part of a Summer of Haskell 2016 project called Native Metaprogramming in Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix Trac #11081 [3]. Ryan S. ----- [1] https://github.com/shayan-najd/NativeMetaprogramming [2] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective [3] https://ghc.haskell.org/trac/ghc/ticket/11081 From ben at smart-cactus.org Fri Aug 5 09:06:45 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 05 Aug 2016 11:06:45 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: <877fbvmvoa.fsf@smart-cactus.org> Ryan Scott writes: > Sorry for not including the full context on that link. It's part of a > Summer of Haskell 2016 project called Native Metaprogramming in > Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix > Trac #11081 [3]. > On this note, it would be great to hear a bit about the state of this project. Shayan, have you written anything describing how things are going? It would be great if you could update the Wiki page [2] describing a bit about the approach you have taken and the current state of your implementation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alan.zimm at gmail.com Fri Aug 5 13:40:15 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 5 Aug 2016 15:40:15 +0200 Subject: RdrName and decorations Message-ID: Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName may have parens or backquotes around it, and may have a preceding keyword out of [forall, pattern, type]. I am slowly teasing out the contextual requirements to determine these, but it seems that they should be captured directly in the AST already. And not as API Annotations. So the question is, does it make sense to do this? Does it belong in the OccName or the RdrName if so? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Aug 5 16:26:46 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 5 Aug 2016 18:26:46 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <877fbvmvoa.fsf@smart-cactus.org> References: <877fbvmvoa.fsf@smart-cactus.org> Message-ID: On 2016-08-05 11:06, Ben Gamari wrote: > Ryan Scott writes: > >> Sorry for not including the full context on that link. It's part of a >> Summer of Haskell 2016 project called Native Metaprogramming in >> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix >> Trac #11081 [3]. >> > On this note, it would be great to hear a bit about the state of this > project. Shayan, have you written anything describing how things are > going? It would be great if you could update the Wiki page [2] > describing a bit about the approach you have taken and the current state > of your implementation. > Just a little aside: AFAICT the idea here was originally to reuse the compiler's internal AST representation. I'd be really interested to hear if that's changed. This compes along with a little cautionary note: The Scala people originally did this for their macro support and it's being abandoned in favor of something called TASTY which is a different (simplified?) representation of the Scala AST. (There were a lot of other problems with the Scala macro implementation which is caused by simply being intimately tied to compiler internals in *other* ways.) Obviously, all of this is AFAIUI and my understanding may not exactly be great, but regardless I think it's worth looking into Scala/TASTY and why the Scala people have (apparently) chosen it as the solution over the existing one. Regards, From sh.najd at gmail.com Fri Aug 5 17:59:49 2016 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 5 Aug 2016 19:59:49 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <877fbvmvoa.fsf@smart-cactus.org> References: <877fbvmvoa.fsf@smart-cactus.org> Message-ID: Hi all, Shayan, have you written anything describing how things are going? Ben, thank you for reaching out. I am not sure about the history and the context of the discussions in this thread so far, but here is a brief description of what we intend to do and how far we have come so far. The idea is simple: allow grand larceny, with a clear conscience! We are trying to allow metaprograms to directly access and reuse the "native" machinery inside the compiler. There is no need to have a separate representation of syntax, and the associated sets of tools, as in Template Haskell, or even as in third-party libraries like Haskell-Src-Exts (HSE) and others in Haskell-Suite. GHC has a "native" representation of terms, with many tools already built on top of that, including the compiler passes like the renamer, or the typechecker. We would certainly like to unify these representations and tools as much as possible, and allow metaprograms to directly access these internal machineries. The eventual goal is indeed more than sole reuse of the AST in GHC (HsSyn); metaprograms should also be able to reuse the "infrastructure" like the different environments and monads used for name resolution or typechecking. If we are to treat `deriving`, and many other similar constructs in the language simply as metaprograms, access to types is *sometimes* crucial: they describe a type-directed elaboration process. I am a strong advocate of such simplifications for both the front-end (i.e., how users perceive constructs in the language), and the back-end (i.e., how the compiler implements them). However, there is a huge, often underestimated, gap between having these constructs as built-in, and having them as yet another metaprogram. The gap is both in theory, e.g., the equational and algebraic properties of the constructs, and in practice, e.g., handling the error messages and maintain the general macro/metaprogramming system allowing for such definitions. Many researchers, including me, have worked on these problems; there is still work to be done. We can discuss some of these related works, if you are interested. For now, as the first step, we are focusing on how to reuse GHC AST (HsSyn) for metaprogramming. The immediate problem with reusing GHC AST is that it comes with a large set of extra fields and constructors carrying the information only necessary for the passes inside GHC. Users (metaprogrammers?) do not want to, and do not need to, deal with these extra fields and constructors. Moreover, the AST should be, to some degree, easy to use, and we have no exact metric for the ease of use. Our solution is twofold, addressing the two mentioned problems: (a) after a rather deep analysis, we have come up with a simple, yet powerful, encoding of extensible ASTs that allows us to extend a base AST with new fields and constructors; (b) we are updating GHC AST to match HSE AST, hence unifying the two (based on its popularity, we can say HSE is easy enough to use). In theory, due to (a), code for GHC passes do not need to change. In practice, due to (b), we may need to update the code in GHC passes in some cases. It is needless to say, that this is all work in progress. Following Simon's suggestion, I am planning to give a talk on this in Haskell Implementors' Workshop in Japan. But since then, for further information, you may be brave enough to read our sketchy notes / pieces of code: - An example using the extensible encoding (a bit outdated variant though): https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HsSyn/Example.hs - Discussion on why this extensible encoding is suitable: https://github.com/shayan-najd/NativeMetaprogramming/wiki/Extensions-&-Annotations - To see progress on unifying HSE AST and GHC AST compare the updated GHC AST at https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HsSyn/SyntaxExtensibleAutoSplitted.hs and the updated HSE AST at https://github.com/shayan-najd/NativeMetaprogramming/blob/master/HSE/SyntaxExtensibleAuto.hs They should be line-by-line comparable unless the comments says so otherwise. There is much to be done without a doubt, specially to synchronise with and learn form communities working on similar topics Yours, Shayan On Fri, Aug 5, 2016 at 11:06 AM, Ben Gamari wrote: > Ryan Scott writes: > > > Sorry for not including the full context on that link. It's part of a > > Summer of Haskell 2016 project called Native Metaprogramming in > > Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix > > Trac #11081 [3]. > > > On this note, it would be great to hear a bit about the state of this > project. Shayan, have you written anything describing how things are > going? It would be great if you could update the Wiki page [2] > describing a bit about the approach you have taken and the current state > of your implementation. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Aug 5 18:08:00 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 5 Aug 2016 14:08:00 -0400 Subject: Can we offer ~ without GADTs or type families? Message-ID: It seems to me that equality constraints could potentially be supported by an implementation with neither GADTs nor type families. Type families don't really seem to have much to do with it, and GADTs are strictly heavier (GADTs ~= ExistentialQuantification + TypeEquality). Could we get a separate LANGUAGE pragma just for equality constraints? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Aug 5 18:08:00 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 5 Aug 2016 14:08:00 -0400 Subject: Deriving tweaking Message-ID: I know there's been some discussion about letting users select the deriving mechanism they want, but I'd like to propose a separate tweak to the defaults. Specifically, it's annoying to have to use three pragmas to let me write newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable) data Bar f a = Bar (f a) deriving (Functor, Foldable, Traversable) and more annoying still that I'll end up with Foldable and Functor instances for Foo that may be much worse than GND-derived ones. The tweaks I'm after: 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri Aug 5 18:15:56 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 5 Aug 2016 14:15:56 -0400 Subject: Can we offer ~ without GADTs or type families? Message-ID: Hi David, > Could we get a separate LANGUAGE pragma just for equality constraints? I think we should, and I don't think we'd even need to introduce a new pragma, since there's already a perfectly good one: -XTypeOperators! After all, there's nothing really that special about (~) other than some typechecking details. A fix to Trac #9194 [1] would give us this. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9194 From ryan.gl.scott at gmail.com Fri Aug 5 18:19:53 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 5 Aug 2016 14:19:53 -0400 Subject: Deriving tweaking Message-ID: You're in luck, David, since both of your requests are currently things that GHC will do. Specifically, > 1. Prefer GND to the built-in derivations for Functor and Foldable, and probably also Eq and Ord. GHC will always derive Eq and Ord instances for newtypes using GND, and will prefer GND when deriving Functor and Foldable instances for newtypes when (1) the -XGeneralizedNewtypeDeriving extension is on, and (2) eta-reducing the type variable is allowed. See [1] for the full details on how GHC chooses when to pick GND behind the scenes. > 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. That's already the case, thanks to Trac #9069. [2] Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Thederivingstrategyresolutionalgorithm [2] https://ghc.haskell.org/trac/ghc/ticket/9069 From ekmett at gmail.com Fri Aug 5 18:27:19 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 5 Aug 2016 14:27:19 -0400 Subject: Can we offer ~ without GADTs or type families? In-Reply-To: References: Message-ID: TypeOperators as a language extension doesn't require a whole lot on the behalf of implementors today. They basically just have to add fixity handling to types. This is a no-brainer for a compiler implementor. It is a simple elaboration and some extra cases to deal with in their parser. The typechecker changes are obvious. Asking them to do all the things to support 'some typechecking details' that aren't entirely trivial to support that same extension is an awful big ask! OutsideIn(X) is a big paper to read, let alone implement, and the only compiler to even try handling (~) today is GHC. -Edward On Fri, Aug 5, 2016 at 2:15 PM, Ryan Scott wrote: > Hi David, > > > Could we get a separate LANGUAGE pragma just for equality constraints? > > I think we should, and I don't think we'd even need to introduce a new > pragma, since there's already a perfectly good one: -XTypeOperators! > After all, there's nothing really that special about (~) other than > some typechecking details. A fix to Trac #9194 [1] would give us this. > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/9194 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Aug 5 18:32:25 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 5 Aug 2016 14:32:25 -0400 Subject: Deriving tweaking In-Reply-To: References: Message-ID: Done and done! Retroactively. How is that for service? =) -Edward On Fri, Aug 5, 2016 at 2:08 PM, David Feuer wrote: > I know there's been some discussion about letting users select the > deriving mechanism they want, but I'd like to propose a separate tweak to > the defaults. Specifically, it's annoying to have to use three pragmas to > let me write > > newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable) > data Bar f a = Bar (f a) deriving (Functor, Foldable, Traversable) > > and more annoying still that I'll end up with Foldable and Functor > instances for Foo that may be much worse than GND-derived ones. > > The tweaks I'm after: > > 1. Prefer GND to the built-in derivations for Functor and Foldable, and > probably also Eq and Ord. > 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Aug 5 18:33:15 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 5 Aug 2016 14:33:15 -0400 Subject: Deriving tweaking In-Reply-To: References: Message-ID: Excellent! On Aug 5, 2016 2:32 PM, "Edward Kmett" wrote: > Done and done! Retroactively. How is that for service? =) > > -Edward > > On Fri, Aug 5, 2016 at 2:08 PM, David Feuer wrote: > >> I know there's been some discussion about letting users select the >> deriving mechanism they want, but I'd like to propose a separate tweak to >> the defaults. Specifically, it's annoying to have to use three pragmas to >> let me write >> >> newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable) >> data Bar f a = Bar (f a) deriving (Functor, Foldable, Traversable) >> >> and more annoying still that I'll end up with Foldable and Functor >> instances for Foo that may be much worse than GND-derived ones. >> >> The tweaks I'm after: >> >> 1. Prefer GND to the built-in derivations for Functor and Foldable, and >> probably also Eq and Ord. >> 2. Make DeriveTraversable imply DeriveFunctor and DeriveFoldable. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri Aug 5 18:35:00 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 5 Aug 2016 14:35:00 -0400 Subject: Can we offer ~ without GADTs or type families? In-Reply-To: References: Message-ID: Good point, I hadn't considered the perspective of other compilers. In that case, I could be persuaded to introduce a separate pragma like -XTypeEqualities, and have -XGADTs and -XTypeFamilies imply -XTypeEqualities for backwards compatibility. Ryan S. On Fri, Aug 5, 2016 at 2:27 PM, Edward Kmett wrote: > TypeOperators as a language extension doesn't require a whole lot on the > behalf of implementors today. They basically just have to add fixity > handling to types. This is a no-brainer for a compiler implementor. It is a > simple elaboration and some extra cases to deal with in their parser. The > typechecker changes are obvious. > > Asking them to do all the things to support 'some typechecking details' that > aren't entirely trivial to support that same extension is an awful big ask! > OutsideIn(X) is a big paper to read, let alone implement, and the only > compiler to even try handling (~) today is GHC. > > -Edward > > On Fri, Aug 5, 2016 at 2:15 PM, Ryan Scott wrote: >> >> Hi David, >> >> > Could we get a separate LANGUAGE pragma just for equality constraints? >> >> I think we should, and I don't think we'd even need to introduce a new >> pragma, since there's already a perfectly good one: -XTypeOperators! >> After all, there's nothing really that special about (~) other than >> some typechecking details. A fix to Trac #9194 [1] would give us this. >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/ticket/9194 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From adam at well-typed.com Fri Aug 5 19:27:49 2016 From: adam at well-typed.com (Adam Gundry) Date: Fri, 5 Aug 2016 20:27:49 +0100 Subject: Can we offer ~ without GADTs or type families? In-Reply-To: References: Message-ID: <5227c8ec-3c45-e14c-df0c-7f3f0eec15e0@well-typed.com> On 05/08/16 19:08, David Feuer wrote: > It seems to me that equality constraints could potentially be supported > by an implementation with neither GADTs nor type families. Type families > don't really seem to have much to do with it, and GADTs are strictly > heavier (GADTs ~= ExistentialQuantification + TypeEquality). > > Could we get a separate LANGUAGE pragma just for equality constraints? I suggested this in #10431 [1], where there is some discussion of the implications. I still think it is a good idea, and I don't think the implementation would be very difficult. All the best, Adam [1] https://ghc.haskell.org/trac/ghc/ticket/10431 -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Sat Aug 6 00:43:54 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Aug 2016 20:43:54 -0400 Subject: [commit: ghc] master: Replace some `length . filter` with `count` (02614fd) In-Reply-To: <20160805224142.3F6ED3A300@ghc.haskell.org> References: <20160805224142.3F6ED3A300@ghc.haskell.org> Message-ID: <1470444234.12087.6.camel@joachim-breitner.de> Hi, Am Freitag, den 05.08.2016, 22:41 +0000 schrieb git at git.haskell.org: > commit 02614fd61f57b599c5e4fd5e85f00a4e1ce37bc7 > Author: Ömer Sinan Ağacan > Date:   Fri Aug 5 20:58:02 2016 +0000 > >     Replace some `length . filter` with `count` Well intended! I wouldn’t be surprised if this is actually making the code worse, considering that "count" is implemented in the “wrong”, stackeating way (whereas lenght . filter could, thanks to list fusion, produce the desired code) count :: (a -> Bool) -> [a] -> Int count _ [] = 0 count p (x:xs) | p x       = 1 + count p xs                | otherwise = count p xs I would say that the regression reported by  https://perf.haskell.org/ghc/#revision/02614fd61f57b599c5e4fd5e85f00a4e1ce37bc7 confirms this, but T6048 is simply unreliable. So practically, it does not seem to matter either way. I’ll change the implementation of count. (Although even then it is not clear that the change is a win, as "length . filter" might fuse with the producer, whereas "count" without a lot of extra hassle will not.) Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ecrockett0 at gmail.com Sat Aug 6 01:14:28 2016 From: ecrockett0 at gmail.com (Eric Crockett) Date: Fri, 5 Aug 2016 21:14:28 -0400 Subject: Can we offer ~ without GADTs or type families? In-Reply-To: <5227c8ec-3c45-e14c-df0c-7f3f0eec15e0@well-typed.com> References: <5227c8ec-3c45-e14c-df0c-7f3f0eec15e0@well-typed.com> Message-ID: As a user who frequently uses ~, but doesn't need the rest of GADTs or TypeFamilies, I'd really like to see a TypeEqualities extension! Eric On Fri, Aug 5, 2016 at 3:27 PM, Adam Gundry wrote: > On 05/08/16 19:08, David Feuer wrote: > > It seems to me that equality constraints could potentially be supported > > by an implementation with neither GADTs nor type families. Type families > > don't really seem to have much to do with it, and GADTs are strictly > > heavier (GADTs ~= ExistentialQuantification + TypeEquality). > > > > Could we get a separate LANGUAGE pragma just for equality constraints? > > I suggested this in #10431 [1], where there is some discussion of the > implications. I still think it is a good idea, and I don't think the > implementation would be very difficult. > > All the best, > > Adam > > [1] https://ghc.haskell.org/trac/ghc/ticket/10431 > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Mon Aug 8 11:28:48 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 8 Aug 2016 11:28:48 +0000 Subject: Improving cost center reports to show residency? Message-ID: One thing that we can't currently see in cost center reports is the residency and because of that cost centers can't be used for fixing memory leaks or reducing max. memory residency. For example, I can have a function that returns an `Int` but allocates lots of intermediate data on the way. In the reports I see this function as allocates a lot, but it has no effect on my program's residency (especially if it runs fast). So I'm thinking of somehow using cost centers for reasoning about memory residency. One idea is to print a summary after every major GC, by doing another pass on the whole heap and recording attributions. This can be used for plotting live data of cost centers over time. (like hp2ps but for cost centers) Another idea is to add "residency" column in the profiling reports. Not sure how to update this column in runtime though. The main use case for me is fixing T1969, but of course this is a very general solution. Does anyone have any other ideas? From rrnewton at gmail.com Mon Aug 8 17:27:16 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Mon, 8 Aug 2016 13:27:16 -0400 Subject: Is Safe Haskell intended to allow segfaults? Message-ID: We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says: *Functions in the IO monad are still allowed and behave as usual. * As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe language you can trust the types", and I'd always assumed that meant Safe Haskell is a type safe language, even in the IO fragment. Was there an explicit decision to allow segfaults and memory corruption? This can happen not just with FFI calls but with uses of Ptrs within Haskell, for example the following: ``` {-# LANGUAGE Safe #-} module Main where import Foreign.Marshal.Alloc import Foreign.Storable import Foreign.Ptr import System.Random fn :: Ptr Int -> IO () fn p = do -- This is kosher: poke p 3 print =<< peek p -- This should crash the system: ix <- randomIO pokeElemOff p ix 0xcc main = alloca fn ``` -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Aug 8 17:34:36 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 8 Aug 2016 13:34:36 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > language you can trust the types", and I'd always assumed that meant Safe > Haskell is a type safe language, even in the IO fragment. Pretty sure it's impossible to allow IO without enabling all of it one way or another. And as soon as you allow *any* IO, you're open to various kinds of failures including segfaults. The only way you will get your type system to prevent that is fully specified dependent typing both in your program *and in the OS level interfaces*. I wish you luck on the latter. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Mon Aug 8 17:41:37 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Mon, 8 Aug 2016 13:41:37 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: > > Pretty sure it's impossible to allow IO without enabling all of it one way > or another. And as soon as you allow *any* IO, you're open to various kinds > of failures including segfaults. The only way you will get your type system > to prevent that is fully specified dependent typing both in your program > *and in the OS level interfaces*. I wish you luck on the latter. > I don't agree. This would seem to imply that type safe / memory safe imperative languages are impossible, and that OCaml/Java/C#/etc are a false promise! Which APIs and dangers are you thinking of? I'm worried about bounds checks on memory access, and the capability of foreign code to poke at arbitrary memory. But other APIs like these should be fine: - IORef API - MVar API - STM API - File IO API -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Aug 8 18:05:59 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 08 Aug 2016 11:05:59 -0700 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: <1470679294-sup-321@sabre> Hello Ryan, The guarantee that Safe Haskell gives with regards to IO is a little subtle and is mentioned in Section 3.1 of the paper, and detailed in Section 5.1. Essentially, to use Safe Haskell, you are responsible for defining the type at which untrusted code is to be called. Using an untrusted value at type IO a in main imposes no safety restrictions by design--it's up to the user of Safe Haskell to decide what kind of security properties it needs out of user code. Edward Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400: > We're trying to spend some cycles pushing on Safe Haskell within the > stackage packages. (It's looking like a slog.) > > But we're running up against some basic questions regarding the core > packages and Safe Haskell guarantees. The manual currently says: > > > > *Functions in the IO monad are still allowed and behave as usual. * > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > language you can trust the types", and I'd always assumed that meant Safe > Haskell is a type safe language, even in the IO fragment. > > Was there an explicit decision to allow segfaults and memory corruption? > This can happen not just with FFI calls but with uses of Ptrs within > Haskell, for example the following: > > > ``` > > {-# LANGUAGE Safe #-} > > module Main where > > import Foreign.Marshal.Alloc > > import Foreign.Storable > > import Foreign.Ptr > > import System.Random > > > fn :: Ptr Int -> IO () > > fn p = do > > -- This is kosher: > > poke p 3 > > print =<< peek p > > -- This should crash the system: > > ix <- randomIO > > pokeElemOff p ix 0xcc > > > > main = alloca fn > > ``` > > > -Ryan From ezyang at mit.edu Mon Aug 8 19:02:20 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 08 Aug 2016 12:02:20 -0700 Subject: Improving cost center reports to show residency? In-Reply-To: References: Message-ID: <1470682767-sup-7324@sabre> Hello Omer, I don't quite understand; is +RTS -hc what you want? That will output a heap profile per cost center, which will give you residency. Is the problem that you need a heap profile every minor GC rather than major GC (e.g. something like https://ghc.haskell.org/trac/ghc/ticket/8504 ?) Edward Excerpts from Ömer Sinan Ağacan's message of 2016-08-08 11:28:48 +0000: > One thing that we can't currently see in cost center reports is the residency > and because of that cost centers can't be used for fixing memory leaks or > reducing max. memory residency. For example, I can have a function that returns > an `Int` but allocates lots of intermediate data on the way. In the reports I > see this function as allocates a lot, but it has no effect on my program's > residency (especially if it runs fast). > > So I'm thinking of somehow using cost centers for reasoning about memory > residency. One idea is to print a summary after every major GC, by doing another > pass on the whole heap and recording attributions. This can be used for plotting > live data of cost centers over time. (like hp2ps but for cost centers) > > Another idea is to add "residency" column in the profiling reports. Not sure how > to update this column in runtime though. > > The main use case for me is fixing T1969, but of course this is a very general > solution. > > Does anyone have any other ideas? From rrnewton at gmail.com Mon Aug 8 20:00:38 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Mon, 8 Aug 2016 16:00:38 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: <1470679294-sup-321@sabre> References: <1470679294-sup-321@sabre> Message-ID: Hi Ed, Thanks, I went back to the paper and read those sections. It sounds like this design heavily reflects the untrusted-code use case. I believe ceding the entire IO monad is too pessimistic, and it's also against the *spirit* of the type safety guarantee mentioned in the paper: "Type safety. In Milner’s famous phrase, well-typed programs do not go wrong. " There's not really very much discussion of this "punting on IO" decision in the paper. The paper mentions not deleting users files as an example of a higher level security policy -- and a reason not to try to lock down IO -- but that's not really the issue here. Sure, there are many use cases that require an RIO newtype, but the memory model and memory protection are really internal to the language. My interest is in a type safe language with a memory model *in the IO monad*. I think it's quite *reasonable to expect Safe Haskell to be as safe as Java! * There are hundreds of thousands or millions of lines of code written in the IO monad [1], and a lot of that code could probably be memory safe by construction. One question I have for people is which of the following they would favor: 1. Redefine -XSafe to guarantee something about IO and its memory safety (and even its memory model) 2. Add a fourth safety level, "SafeExceptIO", that corresponds to the current guarantees, while extending "Safe" to say something about IO. 3. Leave safe Haskell as it is. (2) sounds a bit clunky to me, and I favor (1) most of all. Best, -Ryan [1] 17M lines on hackage total, hard to count how much is in an IO monad or related monad. On Mon, Aug 8, 2016 at 2:05 PM, Edward Z. Yang wrote: > Hello Ryan, > > The guarantee that Safe Haskell gives with regards to IO is a little > subtle and is mentioned in Section 3.1 of the paper, and detailed > in Section 5.1. Essentially, to use Safe Haskell, you are responsible > for defining the type at which untrusted code is to be called. > Using an untrusted value at type IO a in main imposes no safety > restrictions by design--it's up to the user of Safe Haskell to > decide what kind of security properties it needs out of user code. > > Edward > > Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400: > > We're trying to spend some cycles pushing on Safe Haskell within the > > stackage packages. (It's looking like a slog.) > > > > But we're running up against some basic questions regarding the core > > packages and Safe Haskell guarantees. The manual currently says: > > users_guide/safe_haskell.html#safe-language> > > > > > > *Functions in the IO monad are still allowed and behave as usual. * > > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > > language you can trust the types", and I'd always assumed that meant Safe > > Haskell is a type safe language, even in the IO fragment. > > > > Was there an explicit decision to allow segfaults and memory corruption? > > This can happen not just with FFI calls but with uses of Ptrs within > > Haskell, for example the following: > > > > > > ``` > > > > {-# LANGUAGE Safe #-} > > > > module Main where > > > > import Foreign.Marshal.Alloc > > > > import Foreign.Storable > > > > import Foreign.Ptr > > > > import System.Random > > > > > > fn :: Ptr Int -> IO () > > > > fn p = do > > > > -- This is kosher: > > > > poke p 3 > > > > print =<< peek p > > > > -- This should crash the system: > > > > ix <- randomIO > > > > pokeElemOff p ix 0xcc > > > > > > > > main = alloca fn > > > > ``` > > > > > > -Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Mon Aug 8 20:15:12 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 08 Aug 2016 13:15:12 -0700 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> Message-ID: <1470686635-sup-2230@sabre> I think what you are proposing is reasonable. I wasn't present when Safe Haskell's design was originally fleshed out so I don't know why this route wasn't taken. Edward Excerpts from Ryan Newton's message of 2016-08-08 16:00:38 -0400: > Hi Ed, > > Thanks, I went back to the paper and read those sections. > > It sounds like this design heavily reflects the untrusted-code use case. I > believe ceding the entire IO monad is too pessimistic, and it's also > against the *spirit* of the type safety guarantee mentioned in the paper: > > "Type safety. In Milner’s famous phrase, well-typed programs do not go > wrong. " > There's not really very much discussion of this "punting on IO" decision in > the paper. The paper mentions not deleting users files as an example of a > higher level security policy -- and a reason not to try to lock down IO -- > but that's not really the issue here. > > Sure, there are many use cases that require an RIO newtype, but the memory > model and memory protection are really internal to the language. My > interest is in a type safe language with a memory model *in the IO monad*. > I think it's quite *reasonable to expect Safe Haskell to be as safe as > Java! * There are hundreds of thousands or millions of lines of code > written in the IO monad [1], and a lot of that code could probably be > memory safe by construction. > > One question I have for people is which of the following they would favor: > > 1. Redefine -XSafe to guarantee something about IO and its memory safety > (and even its memory model) > 2. Add a fourth safety level, "SafeExceptIO", that corresponds to the > current guarantees, while extending "Safe" to say something about IO. > 3. Leave safe Haskell as it is. > > (2) sounds a bit clunky to me, and I favor (1) most of all. > > Best, > -Ryan > > [1] 17M lines on hackage total, hard to count how much is in an IO monad or > related monad. > > On Mon, Aug 8, 2016 at 2:05 PM, Edward Z. Yang wrote: > > > Hello Ryan, > > > > The guarantee that Safe Haskell gives with regards to IO is a little > > subtle and is mentioned in Section 3.1 of the paper, and detailed > > in Section 5.1. Essentially, to use Safe Haskell, you are responsible > > for defining the type at which untrusted code is to be called. > > Using an untrusted value at type IO a in main imposes no safety > > restrictions by design--it's up to the user of Safe Haskell to > > decide what kind of security properties it needs out of user code. > > > > Edward > > > > Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400: > > > We're trying to spend some cycles pushing on Safe Haskell within the > > > stackage packages. (It's looking like a slog.) > > > > > > But we're running up against some basic questions regarding the core > > > packages and Safe Haskell guarantees. The manual currently says: > > > > users_guide/safe_haskell.html#safe-language> > > > > > > > > > *Functions in the IO monad are still allowed and behave as usual. * > > > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > > > language you can trust the types", and I'd always assumed that meant Safe > > > Haskell is a type safe language, even in the IO fragment. > > > > > > Was there an explicit decision to allow segfaults and memory corruption? > > > This can happen not just with FFI calls but with uses of Ptrs within > > > Haskell, for example the following: > > > > > > > > > ``` > > > > > > {-# LANGUAGE Safe #-} > > > > > > module Main where > > > > > > import Foreign.Marshal.Alloc > > > > > > import Foreign.Storable > > > > > > import Foreign.Ptr > > > > > > import System.Random > > > > > > > > > fn :: Ptr Int -> IO () > > > > > > fn p = do > > > > > > -- This is kosher: > > > > > > poke p 3 > > > > > > print =<< peek p > > > > > > -- This should crash the system: > > > > > > ix <- randomIO > > > > > > pokeElemOff p ix 0xcc > > > > > > > > > > > > main = alloca fn > > > > > > ``` > > > > > > > > > -Ryan > > From davidterei at gmail.com Mon Aug 8 23:32:41 2016 From: davidterei at gmail.com (David Terei) Date: Mon, 8 Aug 2016 16:32:41 -0700 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> Message-ID: Thanks for bringing this up Ryan, it's an interesting direction of thought. It's been a while since we originally designed SafeHaskell, so I can't remember our thinking very well with this area. I believe it came down to the following: * Our primary concern was to be able to 'trust the types', which is perhaps a little weaker than 'type safety'. So IO can do ugly things, but at least we know that, and know what something without IO, or using a restricted IO monad can do. * Our intuition was that offering stronger guarantees about IO would be very difficult -- I don't remember how far we explored this intuition. * We were also motivated very strongly by the security use case, that may have sadly blinded us a little to something more ambitious as you propose. If you have the energy, it'd be great to put some of this thinking into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell) and flesh out a first approximation of what IO API's cause issues. Is it just Ptr not carrying bounds around with it? Maybe, but then we need to secure how Ptr's can be created, which excludes FFI returning Ptr's. I imagine in Java, that I can construct an invalid pointer in foreign code, and then cause segfaults without the Java code having any issues. Just guessing at this, so very interested to know how it's prevented if I can't. Securing the memory model may be very challenging. E.g., as Russ Cox points out, in Go one can use a data race to break type safety. Does GHC-Haskell have any similar issues? What performance impact would result from fixing these edge cases? http://research.swtch.com/gorace I think your (1) proposal is reasonable and desirable, but we'd really want to understand the difficulty further to guide us between 1--3. Cheers, David On 8 August 2016 at 13:00, Ryan Newton wrote: > Hi Ed, > > Thanks, I went back to the paper and read those sections. > > It sounds like this design heavily reflects the untrusted-code use case. I > believe ceding the entire IO monad is too pessimistic, and it's also against > the spirit of the type safety guarantee mentioned in the paper: > > "Type safety. In Milner’s famous phrase, well-typed programs do not go > wrong. " > > There's not really very much discussion of this "punting on IO" decision in > the paper. The paper mentions not deleting users files as an example of a > higher level security policy -- and a reason not to try to lock down IO -- > but that's not really the issue here. > > Sure, there are many use cases that require an RIO newtype, but the memory > model and memory protection are really internal to the language. My > interest is in a type safe language with a memory model in the IO monad. I > think it's quite reasonable to expect Safe Haskell to be as safe as Java! > There are hundreds of thousands or millions of lines of code written in the > IO monad [1], and a lot of that code could probably be memory safe by > construction. > > One question I have for people is which of the following they would favor: > > Redefine -XSafe to guarantee something about IO and its memory safety (and > even its memory model) > Add a fourth safety level, "SafeExceptIO", that corresponds to the current > guarantees, while extending "Safe" to say something about IO. > Leave safe Haskell as it is. > > (2) sounds a bit clunky to me, and I favor (1) most of all. > > Best, > -Ryan > > [1] 17M lines on hackage total, hard to count how much is in an IO monad or > related monad. > > > On Mon, Aug 8, 2016 at 2:05 PM, Edward Z. Yang wrote: >> >> Hello Ryan, >> >> The guarantee that Safe Haskell gives with regards to IO is a little >> subtle and is mentioned in Section 3.1 of the paper, and detailed >> in Section 5.1. Essentially, to use Safe Haskell, you are responsible >> for defining the type at which untrusted code is to be called. >> Using an untrusted value at type IO a in main imposes no safety >> restrictions by design--it's up to the user of Safe Haskell to >> decide what kind of security properties it needs out of user code. >> >> Edward >> >> Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400: >> > We're trying to spend some cycles pushing on Safe Haskell within the >> > stackage packages. (It's looking like a slog.) >> > >> > But we're running up against some basic questions regarding the core >> > packages and Safe Haskell guarantees. The manual currently says: >> > >> > >> > >> > >> > *Functions in the IO monad are still allowed and behave as usual. * >> > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe >> > language you can trust the types", and I'd always assumed that meant >> > Safe >> > Haskell is a type safe language, even in the IO fragment. >> > >> > Was there an explicit decision to allow segfaults and memory corruption? >> > This can happen not just with FFI calls but with uses of Ptrs within >> > Haskell, for example the following: >> > >> > >> > ``` >> > >> > {-# LANGUAGE Safe #-} >> > >> > module Main where >> > >> > import Foreign.Marshal.Alloc >> > >> > import Foreign.Storable >> > >> > import Foreign.Ptr >> > >> > import System.Random >> > >> > >> > fn :: Ptr Int -> IO () >> > >> > fn p = do >> > >> > -- This is kosher: >> > >> > poke p 3 >> > >> > print =<< peek p >> > >> > -- This should crash the system: >> > >> > ix <- randomIO >> > >> > pokeElemOff p ix 0xcc >> > >> > >> > >> > main = alloca fn >> > >> > ``` >> > >> > >> > -Ryan > > From mikhail.glushenkov at gmail.com Tue Aug 9 00:46:10 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Tue, 9 Aug 2016 02:46:10 +0200 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> Message-ID: Hi, On 9 August 2016 at 01:32, David Terei wrote: > I imagine in Java, that I can construct an invalid pointer in foreign > code, and then cause segfaults without the Java code having any > issues. Just guessing at this, so very interested to know how it's > prevented if I can't. Yes, this can be done with JNI, see e.g. [1]. Additionally, by using sun.misc.Unsafe [2], one can cause segfaults even from pure Java. [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf [2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf From rrnewton at gmail.com Tue Aug 9 14:41:44 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 9 Aug 2016 10:41:44 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> Message-ID: On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov wrote: > > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using > sun.misc.Unsafe [2], one can cause segfaults even from pure Java. > [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf > [2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with pure Java code. Good to know about the unsafe interface. On Mon, Aug 8, 2016 at 7:32 PM, David Terei wrote: > > If you have the energy, it'd be great to put some of this thinking > into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell) > and flesh out a first approximation of what IO API's cause issues. Is > it just Ptr not carrying bounds around with it? Maybe, but then we > need to secure how Ptr's can be created, which excludes FFI returning > Ptr's. > Yes, we can add a Wiki page. Btw I was thinking more of kicking FFI/peek/poke outside of the Safe bubble, not changing their operational behavior. First of all, it's nigh impossible to lock down FFI calls. When someone, e.g. Bob Harper , points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell* is the real objet d'art! It's a safe language." Yet it isn't really a full *language* if people cannot write and run programs in it! (Because every program must be ultimately be `main::IO()`.) Kicking out segfaulty features would still leave a safe language that people can write complete programs in. Best, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From minesasecret at gmail.com Tue Aug 9 15:34:09 2016 From: minesasecret at gmail.com (Richard Fung) Date: Tue, 9 Aug 2016 08:34:09 -0700 Subject: Fwd: Help on first ticket In-Reply-To: References: <87vb1ok354.fsf@smart-cactus.org> <7eb267e6aec944a3b07af79d8eb51033@AM3PR30MB019.064d.mgd.msft.net> Message-ID: ---------- Forwarded message ---------- From: Richard Fung Date: Tue, Aug 9, 2016 at 8:33 AM Subject: Re: Help on first ticket To: Simon Peyton Jones It's been a while but I've been able to spend more time on it recently made some progress. I believe I have an idea of what I need to fix in terms of the generating of ModDetails/ModInfo. First off, please tell me if this is wrong.. it seems like ModDetails is made in mkBootModDetailsTc and tidyProgram. In tidyProgram there are several functions which take omit_prags, which I think is automatically set to True on -O0. These are the things we'll have to change because they are used in mkIface_ to generate the [IfaceDecl] used to make ModInfo in addFingerprints. Hopefully I'm understanding that part correctly. However, I'm not really sure how to write a proper test case for this ticket. Also, I think I have an idea of where to start looking for the place the inlining/unfolding happens but pointers definitely wouldn't hurt. Thanks and sorry this is taking me so long! On Fri, Jun 24, 2016 at 12:26 PM, Simon Peyton Jones wrote: > Great. No rush. Yell if you need help. > > > > Simon > > > > *From:* Richard Fung [mailto:minesasecret at gmail.com] > *Sent:* 24 June 2016 19:05 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > > *Subject:* Re: Help on first ticket > > > > Hi Simon, I am making progress but slowly (I only have time to work on > this outside of work unfortunately). > > > > If this needs to be done soon feel free to reassign it to someone else! > Otherwise, while at times I feel like I'm over my head I would like to keep > at it. > > > > On Fri, Jun 24, 2016 at 4:20 AM, Simon Peyton Jones > wrote: > > Richard, did you get on ok? > > Simon > > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben > | Gamari > | Sent: 04 June 2016 23:20 > | To: Richard Fung ; ghc-devs at haskell.org > | Subject: Re: Help on first ticket > | > | Richard Fung writes: > | > | > Hello! I apologize if this isn't the right place to ask; if it isn't > | > please steer me in the right direction. > | > > | Hi Richard! > | > | > Would anyone be willing to advise me on my first ticket? I've been > | > trying to work on it on and off but haven't made much progress on my > | own. > | > > | > It's ticket #9370: https://ghc.haskell.org/trac/ghc/ticket/9370 > | > > | Great, I'm happy to hear that someone has picked this one up. I think > | it is a nice choice for a self-contained newcomers project. > | > | > I think I understand the issue conceptually but I don't know where > | to > | > look for the code that needs to be changed.. > | > > | I don't know where the code responsible for this is off the top of my > | head, however I can provide some pointers. > | > | So the unfoldings you are looking to preserve come from interface > | files. > | The machinery for all of this is in compiler/iface. IfaceSyn.hs is of > | particular interest and there you will find the definition of > | IfaceUnfolding, which is the unfolding representation which is stored > | in the interface file. Unfoldings live inside of IdInfo values, which > | hold various miscellaneous information which we need to preserve about > | a particular Id (identifier). > | > | There is a somewhat useful comment regarding how IdInfo is treated > | above the definition of IfaceIdInfo in IfaceSyn. In particular it > | seems that interface files for modules compiled with -O0 will have > | their IdInfo fields set to NoInfo. It's not clear what happens when an > | interface file is read. However, grepping for NoInfo reveals a use- > | site in TcIface.tcIdInfo which looks interesting (in particular the > | ignore_prags guard). I think this should be enough to get you going on > | the interface file part of this. > | > | The other part of this ticket is deciding whether to use an unfolding > | when considering whether to inline. This will be done in the > | simplifier (compiler/simplCore). Grepping for "inline" and "unfold" in > | simplCore/Simplify.hs (as well as reading the notes in that file) will > | likely be enough to get you started. > | > | Do let me know if you still feel lost or want to discuss this further. > | I look forward to hearing how it goes. > | > | Cheers, > | > | - Ben > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org > > %2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com > > %7c5ce47a744a1448f > | ff5cb08d38cc666b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V22RG%2 > | fAiO1lD5bLCR%2fXz2jv5QCzYAK5HUi6dDaAFQLA%3d > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue Aug 9 20:19:56 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 09 Aug 2016 13:19:56 -0700 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> Message-ID: <1470773806-sup-5366@sabre> If you can execute subprocesses, you could always spawn gdb to attach via ptrace() to the parent process and then poke around memory. Yes this is a "dumb" example but I think it goes to show how important it is to correctly characterize what the threat model is. A "no-segfault" fragment of Haskell doesn't seem so much as a security feature as it is a "good practices" lint pass. Edward Excerpts from Ryan Newton's message of 2016-08-09 10:41:44 -0400: > On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov glushenkov at gmail.com> wrote: > > > > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using > > sun.misc.Unsafe [2], one can cause segfaults even from pure Java. > > [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf > > [2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf > > > Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with > pure Java code. Good to know about the unsafe interface. > > On Mon, Aug 8, 2016 at 7:32 PM, David Terei wrote: > > > > If you have the energy, it'd be great to put some of this thinking > > into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell) > > and flesh out a first approximation of what IO API's cause issues. Is > > it just Ptr not carrying bounds around with it? Maybe, but then we > > need to secure how Ptr's can be created, which excludes FFI returning > > Ptr's. > > > > Yes, we can add a Wiki page. > > Btw I was thinking more of kicking FFI/peek/poke outside of the Safe > bubble, not changing their operational behavior. First of all, it's nigh > impossible to lock down FFI calls. > > When someone, e.g. Bob Harper > , > points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell* > is the real objet d'art! It's a safe language." Yet it isn't really a > full *language* if people cannot write and run programs in it! (Because > every program must be ultimately be `main::IO()`.) Kicking out segfaulty > features would still leave a safe language that people can write complete > programs in. > > Best, > -Ryan From ekmett at gmail.com Tue Aug 9 21:13:30 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 9 Aug 2016 17:13:30 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: I've always treated Safe Haskell as "Safe until you allow IO" -- in that all 'evil' things get tainted by an IO type that you can't get rid of by the usual means. So if you go to run pure Safe Haskell code in say, lambdabot, which doesn't give the user a means to execute IO, it can't segfault if all of the Trustworthy modules you depend upon actually are trustworthy. Trying to shore up segfault safety under Safe in IO seems like a losing proposition. -Edward On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: > We're trying to spend some cycles pushing on Safe Haskell within the > stackage packages. (It's looking like a slog.) > > But we're running up against some basic questions regarding the core > packages and Safe Haskell guarantees. The manual currently says: > > > > *Functions in the IO monad are still allowed and behave as usual. * > As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe > language you can trust the types", and I'd always assumed that meant Safe > Haskell is a type safe language, even in the IO fragment. > > Was there an explicit decision to allow segfaults and memory corruption? > This can happen not just with FFI calls but with uses of Ptrs within > Haskell, for example the following: > > > ``` > > {-# LANGUAGE Safe #-} > > module Main where > > import Foreign.Marshal.Alloc > > import Foreign.Storable > > import Foreign.Ptr > > import System.Random > > > fn :: Ptr Int -> IO () > > fn p = do > > -- This is kosher: > > poke p 3 > > print =<< peek p > > -- This should crash the system: > > ix <- randomIO > > pokeElemOff p ix 0xcc > > > > main = alloca fn > > ``` > > > -Ryan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Wed Aug 10 02:45:40 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 9 Aug 2016 22:45:40 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: I'm hearing that Safe Haskell is great for pure use cases (lambda bot). But that doesn't depend on being able to write arbitrary IO code inside the Safe bubble, does it? In fact *all* of IO could be outside the safe boundary for this use case, could it not? Are there any existing cases where it is important to be able to build up unsafe IO values inside -XSafe code? Edward, why does it seem like a losing proposition? Are there further problems that come to mind? ezyang mentioned the subprocess problem. I don't have a strong opinion on that one. But I tend to think the safe IO language *should* allow subprocess calls, and its a matter of configuring your OS to not allow ptrace in that situation. This would be part of a set of requirements for how to compile and launch a complete "Safe Haskell" *program* in order to get a guarantee. My primary interest is actually not segfault-freedom, per-se, but being able to define a memory model for Safe Haskell (for which I'd suggest sequential consistency). FFI undermines that, and peek/poke seems like it should cluster with FFI as an unsafe feature. I'm not inclined to give a memory model to peek or FFI -- at that level you get what the architecture gives you -- but I do want a memory model for IORefs, IOVectors, etc. We're poking at the Stackage package set now to figure out what pressure point to push on to increase the percentage of Stackage that is Safe. I'll be able to say more when we have more data on dependencies and problem points. Across all of hackage, Safe Haskell has modest use: of the ~100K modules on Hackage, ~636 are marked Safe, ~874 trustworthy, and ~118 Unsafe. It should be easy to check if any of this Safe code is currently importing "Foreign.*" or using FFI. My general plea is that we not give the imperative partition of Haskell too much the short end of the stick [1]. There is oodles of code in IO (or MonadIO), and probably relatively little in "RIO". To my knowledge, we don't have great ways to coin "RIO" newtypes without having to wrap and reexport rather a lot of IO functions. Maybe if APIs like MVars or files were overloaded in a class then GND could do some of the work... -Ryan [1] In safety guarantees, in optimizations, primops, whatever... For instance, I find in microbenchmarks that IO code still runs 2X slower than pure code, even if no IO effects are performed. On Tue, Aug 9, 2016 at 5:13 PM, Edward Kmett wrote: > I've always treated Safe Haskell as "Safe until you allow IO" -- in that > all 'evil' things get tainted by an IO type that you can't get rid of by > the usual means. So if you go to run pure Safe Haskell code in say, > lambdabot, which doesn't give the user a means to execute IO, it can't > segfault if all of the Trustworthy modules you depend upon actually are > trustworthy. > > Trying to shore up segfault safety under Safe in IO seems like a losing > proposition. > > -Edward > > On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: > >> We're trying to spend some cycles pushing on Safe Haskell within the >> stackage packages. (It's looking like a slog.) >> >> But we're running up against some basic questions regarding the core >> packages and Safe Haskell guarantees. The manual currently says: >> >> >> >> *Functions in the IO monad are still allowed and behave as usual. * >> As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe >> language you can trust the types", and I'd always assumed that meant Safe >> Haskell is a type safe language, even in the IO fragment. >> >> Was there an explicit decision to allow segfaults and memory corruption? >> This can happen not just with FFI calls but with uses of Ptrs within >> Haskell, for example the following: >> >> >> ``` >> >> {-# LANGUAGE Safe #-} >> >> module Main where >> >> import Foreign.Marshal.Alloc >> >> import Foreign.Storable >> >> import Foreign.Ptr >> >> import System.Random >> >> >> fn :: Ptr Int -> IO () >> >> fn p = do >> >> -- This is kosher: >> >> poke p 3 >> >> print =<< peek p >> >> -- This should crash the system: >> >> ix <- randomIO >> >> pokeElemOff p ix 0xcc >> >> >> >> main = alloca fn >> >> ``` >> >> >> -Ryan >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 10 02:52:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 9 Aug 2016 22:52:11 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: <1470773806-sup-5366@sabre> References: <1470679294-sup-321@sabre> <1470773806-sup-5366@sabre> Message-ID: On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang wrote: > If you can execute subprocesses, you could always spawn gdb to > attach via ptrace() to the parent process and then poke around > memory. > Don't even need that if you're just talking segfaults, you can always spawn a subprocess "kill -SEGV $PPID" :) Unless you have full control over all the code that could be run in subprocesses, it's not going to be safe much less Safe. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Wed Aug 10 03:15:10 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 9 Aug 2016 23:15:10 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: <1470679294-sup-321@sabre> <1470773806-sup-5366@sabre> Message-ID: Heh, ok, segfaults themselves are a red herring. More precisely: The operational semantics for a SafeIO language should always accurately model its memory state. The application should not compute (take a step in the semantics) in a way that exposes corrupt memory or arbitrary undefined behavior. Nor should it violate the memory model. Moving immediately to the "Terminated" state is fine, whether it be due to out-of-memory, kill -SEGV, cosmic rays, or hardware failure. An FFI call that corrupts memory is bad (may result in arbitrary behavior, not just termination) as is ptrace'ing. Naturally, all Unsafe code is part of the TCB, as is the OS and GHC, and low-level data structure libs and bindings. It's a big TCB. Still, it's something to be able to write an app that doesn't automatically get added to this TCB just by virtue of being an *app* (main::IO). On Tue, Aug 9, 2016 at 10:52 PM, Brandon Allbery wrote: > On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang wrote: > >> If you can execute subprocesses, you could always spawn gdb to >> attach via ptrace() to the parent process and then poke around >> memory. >> > > Don't even need that if you're just talking segfaults, you can always > spawn a subprocess "kill -SEGV $PPID" :) > > Unless you have full control over all the code that could be run in > subprocesses, it's not going to be safe much less Safe. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xichekolas at gmail.com Wed Aug 10 03:22:07 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Tue, 9 Aug 2016 20:22:07 -0700 Subject: enumFromThenTo for Doubles Message-ID: Noticed this today: ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs 86400.0000005062 enumFromThenTo is implemented by numericEnumFromThenTo: https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/libraries/base/GHC/Real.hs#L227 Which probably accumulates error in numericEnumFromThen with the (m+m-n): numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n)) Why not define numericEnumFromThen as: numericEnumFromThen n m = let d = m - n in d `seq` go d n where go delta x = x `seq` (x : go delta (x + delta)) (or with BangPatterns) numericEnumFromThen n m = go (m - n) n where go !delta !x = x : go delta (x + delta) Seems like we'd save a lot of subtractions by using the worker function. From xichekolas at gmail.com Wed Aug 10 03:27:33 2016 From: xichekolas at gmail.com (Andrew Farmer) Date: Tue, 9 Aug 2016 20:27:33 -0700 Subject: enumFromThenTo for Doubles In-Reply-To: References: Message-ID: Turns out the accumulated error is even worse: Prelude> let old x y z = let eftt i j = i : eftt j (j+j-i) in let d = y - x in maximum $ takeWhile (<= z + d) $ eftt x y Prelude> old 0.0 0.1 86400.0 86400.0000005062 Prelude> let new x y z = let d = y - x in let go i = i : go (i + d) in maximum $ takeWhile (<= z + d) $ go x Prelude> new 0.0 0.1 86400.0 86400.00000054126 Sorry to spam the list. :-P Floating point is hard. On Tue, Aug 9, 2016 at 8:22 PM, Andrew Farmer wrote: > Noticed this today: > > ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs > 86400.0000005062 > > enumFromThenTo is implemented by numericEnumFromThenTo: > > https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/libraries/base/GHC/Real.hs#L227 > > Which probably accumulates error in numericEnumFromThen with the (m+m-n): > > numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n)) > > Why not define numericEnumFromThen as: > > numericEnumFromThen n m = let d = m - n in d `seq` go d n > where go delta x = x `seq` (x : go delta (x + delta)) > > (or with BangPatterns) > > numericEnumFromThen n m = go (m - n) n > where go !delta !x = x : go delta (x + delta) > > Seems like we'd save a lot of subtractions by using the worker function. From ekmett at gmail.com Wed Aug 10 03:58:29 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 9 Aug 2016 23:58:29 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: I see three major stories here: 1.) If you remove IO from being able to be compiled inside Safe code _at all_ most packages I have that bother to expose Safe information will have to stop bothering. I'd have to cut up too many APIs into too many fine-grained pieces. This would considerably reduce the utility of Safe Haskell to me. Many of them expose a few combinators here and there that happen to live in IO and I can view offering Safe or Trustworthy to users as a 'the pure stuff looks really pure' guarantee. For the most part it 'just works' and Trustworthy annotations can be put in when I know the semantics of the hacks I'm using under the hood. 2.) Assuming instead that you're talking about a stronger-than-Safe additional language extension, say ReallySafe or SafeIO, it all comes down to what the user is allowed to do in IO, doesn't it? What effects are users granted access to? We don't have a very fine-grained system for IO-effect management, and it seems pretty much any choice you pick for what to put in the sandbox will be wrong for some users, so you'd need some sort of pragma for each IO operation saying what bins it falls into and to track that while type checking, etc. At least then you could say what you are safe with respect to. That all seems to be rather a big mess, roughly equivalent to modeling an effect system for IO operations, and then retroactively categorizing everything, putting a big burden on maintainers and requiring a lot of community buy-in, sight unseen. 3.) On the other hand, someone could _build_ an effect system in Haskell that happens to sit on top of IO, holding effects in an HList, undischarged nullary class constraint, etc. then pull a couple of Trustworthy modules around it for embedding the effects they want to permit and build this today without any compiler support, they'd just have to make a final application-specific Trustworthy wrapper to run whatever effects they want to permit into their program. It is more invasive to the code in question, but it requires zero community organizing and we've already got all the compiler mojo we need. The downside is the Trustworthy wrappers at the bottom of the heap and that it doesn't interoperate with basically anything already written. -Edward On Tue, Aug 9, 2016 at 10:45 PM, Ryan Newton wrote: > I'm hearing that Safe Haskell is great for pure use cases (lambda bot). > But that doesn't depend on being able to write arbitrary IO code inside the > Safe bubble, does it? In fact *all* of IO could be outside the safe > boundary for this use case, could it not? Are there any existing cases > where it is important to be able to build up unsafe IO values inside -XSafe > code? > > Edward, why does it seem like a losing proposition? Are there further > problems that come to mind? ezyang mentioned the subprocess problem. I > don't have a strong opinion on that one. But I tend to think the safe IO > language *should* allow subprocess calls, and its a matter of configuring > your OS to not allow ptrace in that situation. This would be part of a set > of requirements for how to compile and launch a complete "Safe Haskell" > *program* in order to get a guarantee. > > My primary interest is actually not segfault-freedom, per-se, but being > able to define a memory model for Safe Haskell (for which I'd suggest > sequential consistency). FFI undermines that, and peek/poke seems like it > should cluster with FFI as an unsafe feature. I'm not inclined to give a > memory model to peek or FFI -- at that level you get what the architecture > gives you -- but I do want a memory model for IORefs, IOVectors, etc. > > We're poking at the Stackage package set now to figure out what pressure > point to push on to increase the percentage of Stackage that is Safe. I'll > be able to say more when we have more data on dependencies and problem > points. Across all of hackage, Safe Haskell has modest use: of the ~100K > modules on Hackage, ~636 are marked Safe, ~874 trustworthy, and ~118 > Unsafe. It should be easy to check if any of this Safe code is currently > importing "Foreign.*" or using FFI. > > My general plea is that we not give the imperative partition of Haskell > too much the short end of the stick [1]. There is oodles of code in IO (or > MonadIO), and probably relatively little in "RIO". To my knowledge, we > don't have great ways to coin "RIO" newtypes without having to wrap and > reexport rather a lot of IO functions. Maybe if APIs like MVars or files > were overloaded in a class then GND could do some of the work... > > -Ryan > > [1] In safety guarantees, in optimizations, primops, whatever... For > instance, I find in microbenchmarks that IO code still runs 2X slower than > pure code, even if no IO effects are performed. > > > > On Tue, Aug 9, 2016 at 5:13 PM, Edward Kmett wrote: > >> I've always treated Safe Haskell as "Safe until you allow IO" -- in that >> all 'evil' things get tainted by an IO type that you can't get rid of by >> the usual means. So if you go to run pure Safe Haskell code in say, >> lambdabot, which doesn't give the user a means to execute IO, it can't >> segfault if all of the Trustworthy modules you depend upon actually are >> trustworthy. >> >> Trying to shore up segfault safety under Safe in IO seems like a losing >> proposition. >> >> -Edward >> >> On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: >> >>> We're trying to spend some cycles pushing on Safe Haskell within the >>> stackage packages. (It's looking like a slog.) >>> >>> But we're running up against some basic questions regarding the core >>> packages and Safe Haskell guarantees. The manual currently says: >>> >>> >>> >>> *Functions in the IO monad are still allowed and behave as usual. * >>> As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe >>> language you can trust the types", and I'd always assumed that meant Safe >>> Haskell is a type safe language, even in the IO fragment. >>> >>> Was there an explicit decision to allow segfaults and memory >>> corruption? This can happen not just with FFI calls but with uses of Ptrs >>> within Haskell, for example the following: >>> >>> >>> ``` >>> >>> {-# LANGUAGE Safe #-} >>> >>> module Main where >>> >>> import Foreign.Marshal.Alloc >>> >>> import Foreign.Storable >>> >>> import Foreign.Ptr >>> >>> import System.Random >>> >>> >>> fn :: Ptr Int -> IO () >>> >>> fn p = do >>> >>> -- This is kosher: >>> >>> poke p 3 >>> >>> print =<< peek p >>> >>> -- This should crash the system: >>> >>> ix <- randomIO >>> >>> pokeElemOff p ix 0xcc >>> >>> >>> >>> main = alloca fn >>> >>> ``` >>> >>> >>> -Ryan >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Aug 10 08:24:21 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 10 Aug 2016 09:24:21 +0100 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: Right - Safe Haskell provides the minimum that you need to be able to safely run untrusted code: the ability to trust the type system and the module system. Definining a safe subset of IO is usually an application-specific decision, e.g. do you want to allow access to the filesystem but without allowing openFile "/dev/mem"? It's a minefield. Ryan, if you want to give an operational semantics for memory in IO, why not start from the subset of IO that you can accurately model - the basic IO structure together with a set of primitives - and define the semantics for that? That's typically what we do when we're talking about something in the IO monad. Cheers Simon On 10 August 2016 at 04:58, Edward Kmett wrote: > I see three major stories here: > > 1.) If you remove IO from being able to be compiled inside Safe code _at > all_ most packages I have that bother to expose Safe information will have > to stop bothering. I'd have to cut up too many APIs into too many > fine-grained pieces. This would considerably reduce the utility of Safe > Haskell to me. Many of them expose a few combinators here and there that > happen to live in IO and I can view offering Safe or Trustworthy to users > as a 'the pure stuff looks really pure' guarantee. For the most part it > 'just works' and Trustworthy annotations can be put in when I know the > semantics of the hacks I'm using under the hood. > > 2.) Assuming instead that you're talking about a stronger-than-Safe > additional language extension, say ReallySafe or SafeIO, it all comes down > to what the user is allowed to do in IO, doesn't it? What effects are users > granted access to? We don't have a very fine-grained system for IO-effect > management, and it seems pretty much any choice you pick for what to put in > the sandbox will be wrong for some users, so you'd need some sort of pragma > for each IO operation saying what bins it falls into and to track that > while type checking, etc. At least then you could say what you are safe > with respect to. That all seems to be rather a big mess, roughly equivalent > to modeling an effect system for IO operations, and then retroactively > categorizing everything, putting a big burden on maintainers and requiring > a lot of community buy-in, sight unseen. > > 3.) On the other hand, someone could _build_ an effect system in Haskell > that happens to sit on top of IO, holding effects in an HList, undischarged > nullary class constraint, etc. then pull a couple of Trustworthy modules > around it for embedding the effects they want to permit and build this > today without any compiler support, they'd just have to make a final > application-specific Trustworthy wrapper to run whatever effects they want > to permit into their program. It is more invasive to the code in question, > but it requires zero community organizing and we've already got all the > compiler mojo we need. The downside is the Trustworthy wrappers at the > bottom of the heap and that it doesn't interoperate with basically anything > already written. > > -Edward > > On Tue, Aug 9, 2016 at 10:45 PM, Ryan Newton wrote: > >> I'm hearing that Safe Haskell is great for pure use cases (lambda bot). >> But that doesn't depend on being able to write arbitrary IO code inside the >> Safe bubble, does it? In fact *all* of IO could be outside the safe >> boundary for this use case, could it not? Are there any existing cases >> where it is important to be able to build up unsafe IO values inside -XSafe >> code? >> >> Edward, why does it seem like a losing proposition? Are there further >> problems that come to mind? ezyang mentioned the subprocess problem. I >> don't have a strong opinion on that one. But I tend to think the safe IO >> language *should* allow subprocess calls, and its a matter of >> configuring your OS to not allow ptrace in that situation. This would be >> part of a set of requirements for how to compile and launch a complete >> "Safe Haskell" *program* in order to get a guarantee. >> >> My primary interest is actually not segfault-freedom, per-se, but being >> able to define a memory model for Safe Haskell (for which I'd suggest >> sequential consistency). FFI undermines that, and peek/poke seems like it >> should cluster with FFI as an unsafe feature. I'm not inclined to give a >> memory model to peek or FFI -- at that level you get what the architecture >> gives you -- but I do want a memory model for IORefs, IOVectors, etc. >> >> We're poking at the Stackage package set now to figure out what pressure >> point to push on to increase the percentage of Stackage that is Safe. I'll >> be able to say more when we have more data on dependencies and problem >> points. Across all of hackage, Safe Haskell has modest use: of the ~100K >> modules on Hackage, ~636 are marked Safe, ~874 trustworthy, and ~118 >> Unsafe. It should be easy to check if any of this Safe code is currently >> importing "Foreign.*" or using FFI. >> >> My general plea is that we not give the imperative partition of Haskell >> too much the short end of the stick [1]. There is oodles of code in IO (or >> MonadIO), and probably relatively little in "RIO". To my knowledge, we >> don't have great ways to coin "RIO" newtypes without having to wrap and >> reexport rather a lot of IO functions. Maybe if APIs like MVars or files >> were overloaded in a class then GND could do some of the work... >> >> -Ryan >> >> [1] In safety guarantees, in optimizations, primops, whatever... For >> instance, I find in microbenchmarks that IO code still runs 2X slower than >> pure code, even if no IO effects are performed. >> >> >> >> On Tue, Aug 9, 2016 at 5:13 PM, Edward Kmett wrote: >> >>> I've always treated Safe Haskell as "Safe until you allow IO" -- in that >>> all 'evil' things get tainted by an IO type that you can't get rid of by >>> the usual means. So if you go to run pure Safe Haskell code in say, >>> lambdabot, which doesn't give the user a means to execute IO, it can't >>> segfault if all of the Trustworthy modules you depend upon actually are >>> trustworthy. >>> >>> Trying to shore up segfault safety under Safe in IO seems like a losing >>> proposition. >>> >>> -Edward >>> >>> On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton wrote: >>> >>>> We're trying to spend some cycles pushing on Safe Haskell within the >>>> stackage packages. (It's looking like a slog.) >>>> >>>> But we're running up against some basic questions regarding the core >>>> packages and Safe Haskell guarantees. The manual currently says: >>>> >>>> >>>> >>>> *Functions in the IO monad are still allowed and behave as usual. * >>>> As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe >>>> language you can trust the types", and I'd always assumed that meant Safe >>>> Haskell is a type safe language, even in the IO fragment. >>>> >>>> Was there an explicit decision to allow segfaults and memory >>>> corruption? This can happen not just with FFI calls but with uses of Ptrs >>>> within Haskell, for example the following: >>>> >>>> >>>> ``` >>>> >>>> {-# LANGUAGE Safe #-} >>>> >>>> module Main where >>>> >>>> import Foreign.Marshal.Alloc >>>> >>>> import Foreign.Storable >>>> >>>> import Foreign.Ptr >>>> >>>> import System.Random >>>> >>>> >>>> fn :: Ptr Int -> IO () >>>> >>>> fn p = do >>>> >>>> -- This is kosher: >>>> >>>> poke p 3 >>>> >>>> print =<< peek p >>>> >>>> -- This should crash the system: >>>> >>>> ix <- randomIO >>>> >>>> pokeElemOff p ix 0xcc >>>> >>>> >>>> >>>> main = alloca fn >>>> >>>> ``` >>>> >>>> >>>> -Ryan >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Wed Aug 10 14:23:31 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 10 Aug 2016 10:23:31 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: Hi Edward, On Tue, Aug 9, 2016 at 11:58 PM, Edward Kmett wrote: > > 1.) If you remove IO from being able to be compiled inside Safe code _at > all_ most packages I have that bother to expose Safe information will have > to stop bothering. > I definitely wouldn't argue for removing it entirely. But it's good to know that there are instances where IO functions get mixed up in safe modules. I'll try to systematically find all of these on hackage, but in the meantime do you have a sample list of modules? My modest starting proposal is marking certain Foreign.* modules as Unsafe rather than Trustworthy. We'll find all the modules affected. But, again, are there any modules you know of offhand that are affected? They should fall into two categories: 1. Safe modules that must become Trustworthy (if they import Foreign bits, but don't expose the ability to corrupt memory to the clients of their APIs). 2. Safe modules that must become Unsafe or be split further into smaller modules. Obviously (2) is the biggest source of potential disruption. I wouldn't ask anyone to accept a patch on GHC until we'd explored these impacts pretty thoroughly. I'd have to cut up too many APIs into too many fine-grained pieces. > Yeah, the module-level business is pretty annoying. "vector' removed ".Safe" modules and no one has gotten around to adding the ".Unsafe". > 2.) Assuming instead that you're talking about a stronger-than-Safe > additional language extension, say ReallySafe or SafeIO, it all comes down > to what the user is allowed to do in IO, doesn't it? What effects are users > granted access to? We don't have a very fine-grained system for IO-effect > management, and it seems pretty much any choice you pick for what to put in > the sandbox will be wrong for some users, so you'd need some sort of pragma > for each IO operation saying what bins it falls into and to track that > while type checking, etc. > Well, *maybe* it is a slippery slope that leads to a full effect system. But I'd like to see these issues enumerated. Does memory safety as a goal really involve so many different effects? Do you think there will be 1, 3, 10, or 100 things beyond Foreign.Ptr to worry about? 3.) On the other hand, someone could _build_ an effect system in Haskell > that happens to sit on top of IO, holding effects in an HList, undischarged > nullary class constraint, etc. > Well, sure, I hope we will continue to aim for this as well. This is effectively what we do with our "LVish" Par monad, where we use Safe Haskell to ensure users cannot break the effect system in -XSafe code. Best, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Wed Aug 10 15:14:22 2016 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 10 Aug 2016 11:14:22 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: Hi Ryan, I have similar concerns with safety and STM. In particular, lazy validation allows for execution after inconsistent reads from TVars. The obvious problem to avoid is falling into an infinite loop. As long as -fno-omit-yields is used (on every module?) and maybe some other conditions like eventually GC happens, the transaction will be validated and killed off. But other problems can happen. Consider a transactional hash table with an array and some hashes already computed to be inside the array. If an execution sees updated hashes, but not the updated array, then using unsafeRead could lead to a segfault. I don't think this is completely obvious, especially when people will reach for STM precisely to avoid this sort of problem. I worry about code that abstracts over mutable variables that work given sequential execution, but could fail with STM. ByteString can lead to similar issues. Data.ByteString.replicate can be asked to allocate very large pinned data leading to immediate heap overflow. But if the request is from an inconsistent view of data it seams the programmer has already done their due diligence in preventing this from happening! Anyway, I would like to work toward reasoning about these things more precisely. On Wed, Aug 10, 2016 at 10:23 AM, Ryan Newton wrote: > Hi Edward, > > On Tue, Aug 9, 2016 at 11:58 PM, Edward Kmett wrote: >> >> 1.) If you remove IO from being able to be compiled inside Safe code _at >> all_ most packages I have that bother to expose Safe information will have >> to stop bothering. >> > > I definitely wouldn't argue for removing it entirely. But it's good to > know that there are instances where IO functions get mixed up in safe > modules. I'll try to systematically find all of these on hackage, but in > the meantime do you have a sample list of modules? > > My modest starting proposal is marking certain Foreign.* modules as Unsafe > rather than Trustworthy. We'll find all the modules affected. But, again, > are there any modules you know of offhand that are affected? They should > fall into two categories: > > 1. Safe modules that must become Trustworthy (if they import Foreign > bits, but don't expose the ability to corrupt memory to the clients of > their APIs). > 2. Safe modules that must become Unsafe or be split further into > smaller modules. > > Obviously (2) is the biggest source of potential disruption. > > I wouldn't ask anyone to accept a patch on GHC until we'd explored these > impacts pretty thoroughly. > > I'd have to cut up too many APIs into too many fine-grained pieces. >> > > Yeah, the module-level business is pretty annoying. "vector' removed > ".Safe" modules and no one has gotten around to adding the ".Unsafe". > > >> 2.) Assuming instead that you're talking about a stronger-than-Safe >> additional language extension, say ReallySafe or SafeIO, it all comes down >> to what the user is allowed to do in IO, doesn't it? What effects are users >> granted access to? We don't have a very fine-grained system for IO-effect >> management, and it seems pretty much any choice you pick for what to put in >> the sandbox will be wrong for some users, so you'd need some sort of pragma >> for each IO operation saying what bins it falls into and to track that >> while type checking, etc. >> > > Well, *maybe* it is a slippery slope that leads to a full effect system. > But I'd like to see these issues enumerated. Does memory safety as a goal > really involve so many different effects? Do you think there will be 1, 3, > 10, or 100 things beyond Foreign.Ptr to worry about? > > 3.) On the other hand, someone could _build_ an effect system in Haskell >> that happens to sit on top of IO, holding effects in an HList, undischarged >> nullary class constraint, etc. >> > > Well, sure, I hope we will continue to aim for this as well. This is > effectively what we do with our "LVish" Par monad, where we use Safe > Haskell to ensure users cannot break the effect system in -XSafe code. > > Best, > -Ryan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfoner at seas.upenn.edu Wed Aug 10 18:40:23 2016 From: kfoner at seas.upenn.edu (Kenny Foner) Date: Wed, 10 Aug 2016 18:40:23 +0000 Subject: =?UTF-8?Q?=5BANNOUNCE=5D_Hac_=CF=86=3A_a_Haskell_Exchange_in_Philadelphi?= =?UTF-8?Q?a=2C_Oct_21=E2=80=9323?= Message-ID: Hello Haskellers, Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Oct. 21–23, 2016, at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you’re working on or offer to help someone else on a project of theirs. Come give a talk if you’ve got something to share. Come to learn something new. What do we mean by a “Haskell Exchange”? Less pressurized than a hackathon, more informal than a conference, bigger than a meetup – Hac Phi is a weekend where academics, professionals, and hobbyists can all meet, mingle, hack on each others’ projects, and generally have a good time. (And it’s not to be confused with the Haskell eXchange, an entirely different event.) All the details are on the wiki page ; please register online if you’re coming. We hope to see you there! —The Hac φ team Antal Spector-Zabusky Kenny Foner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Wed Aug 10 20:48:30 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 10 Aug 2016 16:48:30 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: Hi Simon, On Wed, Aug 10, 2016 at 4:24 AM, Simon Marlow > wrote: > Definining a safe subset of IO is usually an application-specific > decision, e.g. do you want to allow access to the filesystem but without > allowing openFile "/dev/mem"? It's a minefield. > I respect your intuition that this is a "minefield" (and Edward's "big mess"), but I still want to unpack this further. I would propose that a MemSafe app is a two-part contract that is half an OS responsibility and half language/runtime responsibility. 1. OS: guarantee that all system calls (including file access) from the process do not violate the processes memory, outside of certain opt-in DMA regions. 2. Lang/runtime: create a binary "ensuring" that all instructions executed in the process maintain the type safety of memory and follow the memory model. (Scare quotes due to large TCB.) With this division, "/dev/mem" and subprocess/ptrace are definitely the job of the OS or containerization. Blame for a bug would fall to category 1. A MemSafe app needs a launcher/harness to check that category 1 is enforced properly. I'm not proposing that GHC needs to generate that. It should be separate. Ryan, if you want to give an operational semantics for memory in IO, why > not start from the subset of IO that you can accurately model - the basic > IO structure together with a set of primitives - and define the semantics > for that? That's typically what we do when we're talking about something > in the IO monad. > Yes, indeed, that has been the approach for decades (and the same thing you and I do with other monads like Par ). There's something unsatisfying here though -- we love to build model languages that include the effects we want to talk about *at that time* -- perhaps just MVars, just putChar, or just STM. But of course there's a big leap from these small treatments to GHC, with its multitude of moving parts. That's partly why I think SafeHaskell is so great; it's a Full Language which aims for serious, statically enforced guarantees. Well, almost a full language ;-). You can't run programs in it, unless you *extend* the TCB. It's kind of like Rust if you were required to use an "unsafe" block to write main(). Anyway, here's a draft paper that does propose a small model language. It adds a memory model to Haskell plus IORefs/STRefs/TVars, and explains how, when executed on a machine with relaxed TSO memory (store buffers), the IO writes need to be fenced, but the ST and STM ones don't: http://www.cs.indiana.edu/~rrnewton/papers/sc-haskell_draft.pdf Do we need a memory model? I concur with David Terei's arguments from 5 years ago . Note however, that the implementation in this paper is TSO only. Implementation on ARM would be a bit different, but the relationship between IO/ST and IO/STM would stay the same. Ryan Yates & others, I'm curious if you think the treatment of STM is satisfactory. Like ppopp05, we do not model retrying explicitly, and our goal here is to show the interaction of the different effects. Cheers, -Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Aug 10 20:50:12 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 10 Aug 2016 20:50:12 +0000 Subject: enumFromThenTo for Doubles In-Reply-To: References: Message-ID: Sounds somewhat plausible. By all means give it a try. S -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Andrew Farmer Sent: 10 August 2016 04:22 To: ghc-devs at haskell.org Subject: enumFromThenTo for Doubles Noticed this today: ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs 86400.0000005062 enumFromThenTo is implemented by numericEnumFromThenTo: https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9bbcef346f1/libraries/base/GHC/Real.hs#L227 Which probably accumulates error in numericEnumFromThen with the (m+m-n): numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n)) Why not define numericEnumFromThen as: numericEnumFromThen n m = let d = m - n in d `seq` go d n where go delta x = x `seq` (x : go delta (x + delta)) (or with BangPatterns) numericEnumFromThen n m = go (m - n) n where go !delta !x = x : go delta (x + delta) Seems like we'd save a lot of subtractions by using the worker function. _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=02%7c01%7csimonpj%40microsoft.com%7c65f112900fb44b7186a408d3c0cd8631%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636063961357184976&sdata=Gz0DQ%2fGEUIyfHtmAjdbxpBt3YEnxbpoKKiygnCb%2fhYo%3d From qdunkan at gmail.com Wed Aug 10 22:05:50 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 10 Aug 2016 15:05:50 -0700 Subject: enumFromThenTo for Doubles In-Reply-To: References: Message-ID: Way back when I started with haskell I noticed this, and switched to using this: -- | Enumerate an inclusive range. Uses multiplication instead of successive -- addition to avoid loss of precision. -- -- Also it doesn't require an Enum instance. range :: (Num a, Ord a) => a -> a -> a -> [a] range start end step = go 0 where go i | step >= 0 && val > end = [] | step < 0 && val < end = [] | otherwise = val : go (i+1) where val = start + (i*step) It's always seemed better in every way, except syntax convenience. Wouldn't any approach with successive addition lose precision? On Tue, Aug 9, 2016 at 8:22 PM, Andrew Farmer wrote: > Noticed this today: > > ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs > 86400.0000005062 > > enumFromThenTo is implemented by numericEnumFromThenTo: > > https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9 > bbcef346f1/libraries/base/GHC/Real.hs#L227 > > Which probably accumulates error in numericEnumFromThen with the (m+m-n): > > numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m > (m+m-n)) > > Why not define numericEnumFromThen as: > > numericEnumFromThen n m = let d = m - n in d `seq` go d n > where go delta x = x `seq` (x : go delta (x + delta)) > > (or with BangPatterns) > > numericEnumFromThen n m = go (m - n) n > where go !delta !x = x : go delta (x + delta) > > Seems like we'd save a lot of subtractions by using the worker function. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Aug 11 10:36:01 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 11 Aug 2016 10:36:01 +0000 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Ryan I've been on holiday, and there's been a lot of traffic on this deriving-strategy thread. Would you like to send an email summarising the state of play. Eg * Current specification is here: ... * Patch is here: ... (complete?) * Unresolved issues? Ready to review? Thanks Simon | -----Original Message----- | From: Ryan Scott [mailto:ryan.gl.scott at gmail.com] | Sent: 02 August 2016 23:59 | To: Simon Peyton Jones | Cc: Richard Eisenberg ; Andres Loeh ; GHC developers | Subject: Re: Request for feedback: deriving strategies syntax | | Thanks for the feedback, everyone! I've typed up the developments so | far in the DerivingStrategies Haskell wiki page [1]. | | Here's what seems to be the consensus: | | * The syntax in which actual keywords are used to designate deriving | strategies was the clear favorite. | * In particular, a slight edge goes to the form in which multiple | deriving clauses can be placed after a datatype, and each `deriving` | clause has its own (optional) strategy keyword, as opposed to putting | the keyword directly in front of the derived type. | * The `builtin` keyword was poorly received. There isn't a obvious | candidate to replace it, and several of us like the word `bespoke`, so | it looks like `bespoke` will be the replacement. (If someone ends up | complaining about it, we've got several other choices.) | | | Any other questions or comments? | | Ryan S. | ----- | [1] | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate | gies | | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones | wrote: | > I'm not following all the details here, and I do not feel strongly | about syntax; but I do hope that you'll update the wiki page to reflect | the discussion. | > | > Thanks | > | > Simon | > | > -----Original Message----- | > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan | Scott | > Sent: 18 July 2016 15:00 | > To: Richard Eisenberg | > Cc: Andres Loeh ; GHC developers | > Subject: Re: Request for feedback: deriving strategies syntax | > | > Andres, | > | >> The objects probably shouldn't be type synonyms, but they could be | >> special datatypes or type families, perhaps. | > | > I considered that - we already have some special datatypes, type | families, and type classes currently. However, neither datatypes nor | type families are allowed to appear as the outermost type in an instance | declaration (unless we bake in a very prominent exception to this rule), | and if we imbued type classes with this magic, one might think that | "deriving (GND Eq)" means we're deriving an instance for the magical GND | class, not Eq. So those approaches don't sound satisfying to me on a | cursory examination. | > | > Richard, | > | >> The one idea I can suggest in this space (somewhat tongue-in-cheek, | >> but feel free to take it seriously) is `bespoke` | > | > It might be a tongue-in-cheek suggestion, but I _really_ like it. It | captures the intended semantics better than any other previous | suggestion, I think. And we're already going to be appropriating a new | keyword with "anyclass", so why not take "bespoke" as well? :) | > | > Please stop me if I've slipped into madness here. | > | >> I thought about verbosity here, and it's not clear which one is more | verbose. For example, I frequently define a new newtype and then wish to | use GND to derive a whole host of instances. In this case (is it | common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter | than putting newtype on each class name. | > | > That's a good point. Another thing to consider is that I suspect in | 90% of the time, users are only going to be reaching for - | XDerivingStrategies in the scenario when they enable both - | XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when | they want to derive instances for newtypes, and as you said, you | typically derive several instances at a time when defining newtypes. | > Therefore, it seems less noisy to factor out the deriving strategy | names so that readers can tell at a glance which batch of instances are | newtype-derived and which are anyclass-derived, instead of having to | read a keyword before every single type. | > | > Plus, on a superficial level, I like keeping the deriving strategy | name outside of the parentheses. I think it makes clear that these | keywords aren't modifying the type we're deriving, only the means by | which we're deriving it. Of course, you may feel differently than I do, | so please speak up if you disagree! | > | > | > Ryan S. | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07c | ede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKU | dDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d From ryan.gl.scott at gmail.com Thu Aug 11 13:30:03 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 11 Aug 2016 09:30:03 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi Simon, > * Current specification is here: ... It's in a Haskell wiki page: [1]. This summarizes the current proposed syntax for -XDerivingStrategies, how GHC will choose a strategy in the absence of an explicit strategy, and also goes over some alternative syntaxes that have been proposed previously for the sake of archiving. > * Patch is here: ... (complete?) It's on Phabricator: [2]. > * Unresolved issues? Ready to review? It's ready for review. It's incorporated all of the changes discussed on this e-mail thread, including renaming the "builtin" strategy to "bespoke", and including a link to the DerivingStrategies wiki in a Note. You left some inline comments on an earlier draft—I responded to some of them with questions [3], since I wasn't clear what you were asking. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies [2] https://phabricator.haskell.org/D2280 [3] https://phabricator.haskell.org/D2280#inline-20129 On Thu, Aug 11, 2016 at 6:36 AM, Simon Peyton Jones wrote: > Ryan > > I've been on holiday, and there's been a lot of traffic on this deriving-strategy thread. > > Would you like to send an email summarising the state of play. Eg > * Current specification is here: ... > * Patch is here: ... (complete?) > * Unresolved issues? Ready to review? > > Thanks > > Simon > > | -----Original Message----- > | From: Ryan Scott [mailto:ryan.gl.scott at gmail.com] > | Sent: 02 August 2016 23:59 > | To: Simon Peyton Jones > | Cc: Richard Eisenberg ; Andres Loeh | loeh.de>; GHC developers > | Subject: Re: Request for feedback: deriving strategies syntax > | > | Thanks for the feedback, everyone! I've typed up the developments so > | far in the DerivingStrategies Haskell wiki page [1]. > | > | Here's what seems to be the consensus: > | > | * The syntax in which actual keywords are used to designate deriving > | strategies was the clear favorite. > | * In particular, a slight edge goes to the form in which multiple > | deriving clauses can be placed after a datatype, and each `deriving` > | clause has its own (optional) strategy keyword, as opposed to putting > | the keyword directly in front of the derived type. > | * The `builtin` keyword was poorly received. There isn't a obvious > | candidate to replace it, and several of us like the word `bespoke`, so > | it looks like `bespoke` will be the replacement. (If someone ends up > | complaining about it, we've got several other choices.) > | > | > | Any other questions or comments? > | > | Ryan S. > | ----- > | [1] > | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate > | gies > | > | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones > | wrote: > | > I'm not following all the details here, and I do not feel strongly > | about syntax; but I do hope that you'll update the wiki page to reflect > | the discussion. > | > > | > Thanks > | > > | > Simon > | > > | > -----Original Message----- > | > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan > | Scott > | > Sent: 18 July 2016 15:00 > | > To: Richard Eisenberg > | > Cc: Andres Loeh ; GHC developers | devs at haskell.org> > | > Subject: Re: Request for feedback: deriving strategies syntax > | > > | > Andres, > | > > | >> The objects probably shouldn't be type synonyms, but they could be > | >> special datatypes or type families, perhaps. > | > > | > I considered that - we already have some special datatypes, type > | families, and type classes currently. However, neither datatypes nor > | type families are allowed to appear as the outermost type in an instance > | declaration (unless we bake in a very prominent exception to this rule), > | and if we imbued type classes with this magic, one might think that > | "deriving (GND Eq)" means we're deriving an instance for the magical GND > | class, not Eq. So those approaches don't sound satisfying to me on a > | cursory examination. > | > > | > Richard, > | > > | >> The one idea I can suggest in this space (somewhat tongue-in-cheek, > | >> but feel free to take it seriously) is `bespoke` > | > > | > It might be a tongue-in-cheek suggestion, but I _really_ like it. It > | captures the intended semantics better than any other previous > | suggestion, I think. And we're already going to be appropriating a new > | keyword with "anyclass", so why not take "bespoke" as well? :) > | > > | > Please stop me if I've slipped into madness here. > | > > | >> I thought about verbosity here, and it's not clear which one is more > | verbose. For example, I frequently define a new newtype and then wish to > | use GND to derive a whole host of instances. In this case (is it > | common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter > | than putting newtype on each class name. > | > > | > That's a good point. Another thing to consider is that I suspect in > | 90% of the time, users are only going to be reaching for - > | XDerivingStrategies in the scenario when they enable both - > | XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when > | they want to derive instances for newtypes, and as you said, you > | typically derive several instances at a time when defining newtypes. > | > Therefore, it seems less noisy to factor out the deriving strategy > | names so that readers can tell at a glance which batch of instances are > | newtype-derived and which are anyclass-derived, instead of having to > | read a keyword before every single type. > | > > | > Plus, on a superficial level, I like keeping the deriving strategy > | name outside of the parentheses. I think it makes clear that these > | keywords aren't modifying the type we're deriving, only the means by > | which we're deriving it. Of course, you may feel differently than I do, > | so please speak up if you disagree! > | > > | > > | > Ryan S. > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has > | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07c > | ede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKU > | dDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d From cma at bitemyapp.com Thu Aug 11 17:13:04 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 11 Aug 2016 12:13:04 -0500 Subject: Noticing how the Rust team is improving compiler errors Message-ID: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html I'd particularly note that their compiler errors were dramatically better to begin with, now they're doing this. Thought the list would be interested in this. --- Chris From karolinadrobnik at gmail.com Thu Aug 11 17:30:41 2016 From: karolinadrobnik at gmail.com (Karolina Drobnik) Date: Thu, 11 Aug 2016 19:30:41 +0200 Subject: Suggesting RankNTypes for ill-formed types Message-ID: Hello everyone, I am working on my first ticket (#11669, linked below) and I have some doubts after a little bit of hacking. There was a hint that an error message should be changed from the one suggesting RankNTypes to ExplicitForall. In my opinion it would be quite confusing for the user, especially where the type is ill-formed. A plain parse error should be shown here. It is clear that it should be done in such a way after turning on one of the extensions, but what about the situation where proposed fix (suggesting RankNTypes/ExplicitForall) won't work? We should be able to distinguish ill-formed type from the correct one, even before the extension activation. To be honest - I don't know how to do it. Additionally, I am not sure if we can assume that an user wants to use arbitrary rank (which implies ExplicitForall) or just a forall keyword. I am for the second one, but it is just my assumption. And the last minor thing - a type formed in this way also rises an error suggesting using RankNTypes (as we know that wouldn't solve the problem): f :: a. -> Int f = undefined Maybe we could treat it as a typo (simple parse error) and propose an extension activation only when forall was parsed earlier? That could be tricky. I'd appreciate some thoughts on this issue because I felt a bit lost after digging around the parser. Best regards, Karolina --------------------------------------------------------- #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Thu Aug 11 18:45:02 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 11 Aug 2016 21:45:02 +0300 Subject: Suggesting RankNTypes for ill-formed types In-Reply-To: References: Message-ID: FWIW. Often when I encounter that error, I want `ScopedTypeVariables`, yet my code doesn’t always has the scoped type variable used. So even GHC could parse further and propose it to me, there isn’t anything from to do it :( I don’t know if many use /just/ `ExplicitForAll`... - Oleg > On 11 Aug 2016, at 20:30, Karolina Drobnik wrote: > > Hello everyone, > > I am working on my first ticket (#11669, linked below) > and I have some doubts after a little bit of hacking. > > There was a hint that an error message should be > changed from the one suggesting RankNTypes to ExplicitForall. > In my opinion it would be quite confusing for the user, especially where > the type is ill-formed. A plain parse error should be shown here. > > It is clear that it should be done in such a way after turning on one > of the extensions, but what about the situation where proposed > fix (suggesting RankNTypes/ExplicitForall) won't work? > We should be able to distinguish ill-formed type from the correct one, > even before the extension activation. To be honest - I don't know how to do it. > > Additionally, I am not sure if we can assume that an user wants > to use arbitrary rank (which implies ExplicitForall) or just a forall keyword. > I am for the second one, but it is just my assumption. > > And the last minor thing - a type formed in this way also rises an error > suggesting using RankNTypes (as we know that wouldn't solve the problem): > > f :: a. -> Int > f = undefined > > Maybe we could treat it as a typo (simple parse error) and propose > an extension activation only when forall was parsed earlier? > That could be tricky. > > I'd appreciate some thoughts on this issue because I felt a bit lost > after digging around the parser. > > Best regards, > > Karolina > --------------------------------------------------------- > #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ezyang at mit.edu Thu Aug 11 19:07:16 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 11 Aug 2016 12:07:16 -0700 Subject: Landing Backpack in HEAD Message-ID: <1470942422-sup-8643@sabre> Hello friends, I'm hoping to land Backpack (the patch is two years in the making now!) for GHC 8.2, even though 8.2 is intended to be a stabilization and performance release. In this email, I will make the case that the Backpack patch is relatively self-contained and will not affect non-Backpack users, and explain how you might be affected by the patch. The most recent patchset can be found at https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The Backpack patch" in the commit log, since I plan on squashing these commits before committing. OK, here is what is in the patchset that affects non-Backpack users: - The primary, overarching change is that there is now a distinction between "semantic" and "identity" modules. This solves a problem with hsig files: suppose you have A.hsig which defines data T in package p. The resulting A.hi is most accurately identified as p[A=]:A; however, the Name for T should be .T, not p[A=]:A.T. The former is an identity module (it *identifies* interfaces), whereas the latter is a semantic module (it is what is used in names). Without Backpack, these two identities are always the same. There are a number of places in the existing codepaths where we have to distinguish between the two concepts (sometimes you want semantic, sometimes you want identity); we DEFAULT to the identity module but I fix a few cases where semantic modules were desired instead. - UnitId is generalized to also record how a component is instantiated (a mapping from module names to modules.) Without Backpack this is blank and equivalent to the existing UnitId. - Packages has been refactored to also handle Backpack `-unit-id` flags, since we have to do some extra work to determine what inherited signatures merge where. - The patch REVERTS all of the old support we had for hsig files; -sig-of is no more. spinda had mentioned that Liquid Haskell used this in some cases, and I'm looking at supporting *just* their particular use-case. - A new driver mode --backpack, which process test.bkp files. This mode is used PURELY for testing, and end users are not supposed to use it. These all live in their own modules (BkpSyn, DriverBkp) except for some modest, convenient extensions to the lexer and parser to parse multiple modules at once. The patch also comes with rewritten typechecking support for hsig files, and instantiating indefinite packages on the fly, but these are all standalone pieces of functionality which are not tied to any existing compiler infrastructure. Thanks, Edward From howard_b_golden at yahoo.com Thu Aug 11 20:24:28 2016 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Thu, 11 Aug 2016 20:24:28 +0000 (UTC) Subject: Landing Backpack in HEAD In-Reply-To: <1470942422-sup-8643@sabre> References: <1470942422-sup-8643@sabre> Message-ID: <705541291.745936.1470947068032@mail.yahoo.com> Hi, I created a stub Backpack entry in the Haskell wiki using the abstract of the paper. Howard From ekmett at gmail.com Thu Aug 11 20:48:34 2016 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 11 Aug 2016 16:48:34 -0400 Subject: enumFromThenTo for Doubles In-Reply-To: References: Message-ID: Good catch. Adding and subtracting over and over relying on massive cancellation over and over is a recipe for floating point disaster! That said, so is adding small things to a large thing over and over, you'll accumulate the rounding error from the addition of small numbers to the large base. An even better fix would be then to track the base and the current accumulated total delta from the base and do a final addition at the end. Then you only ever add like sized step sizes together before adding them to the base. This would stage the additions such that you get another matissa sized window of possible accumulation. Something like: enumFromThen n m = go (n - m) n 0 where go !d !b !a = db `seq` db : go d b (a + d) where db = d + b which probably beats Kahan in practice, Kahan-Babuška-Neumaier should be more stable still, and there are other techniques that go further into accuracy at the cost of significant performance. But we don't need a general number summation algorithm. All the numbers except the base are the same, we have a final hammer available to us: just do multiplication of the delta by the number of steps and add it to the base. That should be the most numerically stable thing possible, given that we are forced to do at least the first massive cancellation between the from and then steps by the API we have to meet, but I don't have benchmarks to say which technique wins in practice. -Edward On Tue, Aug 9, 2016 at 11:22 PM, Andrew Farmer wrote: > Noticed this today: > > ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs > 86400.0000005062 > > enumFromThenTo is implemented by numericEnumFromThenTo: > > https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9 > bbcef346f1/libraries/base/GHC/Real.hs#L227 > > Which probably accumulates error in numericEnumFromThen with the (m+m-n): > > numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m > (m+m-n)) > > Why not define numericEnumFromThen as: > > numericEnumFromThen n m = let d = m - n in d `seq` go d n > where go delta x = x `seq` (x : go delta (x + delta)) > > (or with BangPatterns) > > numericEnumFromThen n m = go (m - n) n > where go !delta !x = x : go delta (x + delta) > > Seems like we'd save a lot of subtractions by using the worker function. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Aug 12 13:49:04 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 12 Aug 2016 09:49:04 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: As for a sample list of modules, let's just start with your very first example, Foreign.Ptr: In and of itself nothing in Foreign.Ptr is unsafe! It allows a bit of arithmetic on a type you can't actually use with anything, and provides an IO action mixed into an otherwise pure module that happens to create a FunPtr slot from a haskell function. In fact this module is a textbook example of an otherwise perfectly cromulent Trustworthy module today that happens to have a single IO action in it. I can grab Ptr from it, use its Storable instance to make a default signature for other safe code and still be perfectly safe. It gives no tools for manipulating the contents of the Ptr. It is no more dangerous than an Int with a phantom type argument. You could randomly declare that this module is Unsafe because it combines badly with APIs that would be safe if you could rely on any Ptr T actually pointing to a T, and that users could then be granted the power to ferry them around, but we don't trust a user to be able to do that today. It's the combinators that read/write to a Ptr are the dangerous bits, not pure math. -Edward On Wed, Aug 10, 2016 at 10:23 AM, Ryan Newton wrote: > Hi Edward, > > On Tue, Aug 9, 2016 at 11:58 PM, Edward Kmett wrote: >> >> 1.) If you remove IO from being able to be compiled inside Safe code _at >> all_ most packages I have that bother to expose Safe information will have >> to stop bothering. >> > > I definitely wouldn't argue for removing it entirely. But it's good to > know that there are instances where IO functions get mixed up in safe > modules. I'll try to systematically find all of these on hackage, but in > the meantime do you have a sample list of modules? > > My modest starting proposal is marking certain Foreign.* modules as Unsafe > rather than Trustworthy. We'll find all the modules affected. But, again, > are there any modules you know of offhand that are affected? They should > fall into two categories: > > 1. Safe modules that must become Trustworthy (if they import Foreign > bits, but don't expose the ability to corrupt memory to the clients of > their APIs). > 2. Safe modules that must become Unsafe or be split further into > smaller modules. > > Obviously (2) is the biggest source of potential disruption. > > I wouldn't ask anyone to accept a patch on GHC until we'd explored these > impacts pretty thoroughly. > > I'd have to cut up too many APIs into too many fine-grained pieces. >> > > Yeah, the module-level business is pretty annoying. "vector' removed > ".Safe" modules and no one has gotten around to adding the ".Unsafe". > > >> 2.) Assuming instead that you're talking about a stronger-than-Safe >> additional language extension, say ReallySafe or SafeIO, it all comes down >> to what the user is allowed to do in IO, doesn't it? What effects are users >> granted access to? We don't have a very fine-grained system for IO-effect >> management, and it seems pretty much any choice you pick for what to put in >> the sandbox will be wrong for some users, so you'd need some sort of pragma >> for each IO operation saying what bins it falls into and to track that >> while type checking, etc. >> > > Well, *maybe* it is a slippery slope that leads to a full effect system. > But I'd like to see these issues enumerated. Does memory safety as a goal > really involve so many different effects? Do you think there will be 1, 3, > 10, or 100 things beyond Foreign.Ptr to worry about? > > 3.) On the other hand, someone could _build_ an effect system in Haskell >> that happens to sit on top of IO, holding effects in an HList, undischarged >> nullary class constraint, etc. >> > > Well, sure, I hope we will continue to aim for this as well. This is > effectively what we do with our "LVish" Par monad, where we use Safe > Haskell to ensure users cannot break the effect system in -XSafe code. > > Best, > -Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Fri Aug 12 16:58:53 2016 From: rrnewton at gmail.com (Ryan Newton) Date: Fri, 12 Aug 2016 12:58:53 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: Yes, it is peek and poke that are dangerous. It was Foreign.Storable that I wanted to mark as Unsafe. But we do sometimes run into examples where there's an A and a B, and if you import both, you can make A+B which blows up. So preventing access to A+B may mean arbitrarily marking one or the other (or both) as Unsafe. What I was hoping for examples of are modules you have that are Safe and import Foreign.Storable. On Fri, Aug 12, 2016 at 9:49 AM, Edward Kmett wrote: > As for a sample list of modules, let's just start with your very first > example, Foreign.Ptr: > > In and of itself nothing in Foreign.Ptr is unsafe! It allows a bit of > arithmetic on a type you can't actually use with anything, and provides an > IO action mixed into an otherwise pure module that happens to create a > FunPtr slot from a haskell function. In fact this module is a textbook > example of an otherwise perfectly cromulent Trustworthy module today that > happens to have a single IO action in it. > > I can grab Ptr from it, use its Storable instance to make a default > signature for other safe code and still be perfectly safe. > > It gives no tools for manipulating the contents of the Ptr. It is no more > dangerous than an Int with a phantom type argument. > > You could randomly declare that this module is Unsafe because it combines > badly with APIs that would be safe if you could rely on any Ptr T actually > pointing to a T, and that users could then be granted the power to ferry > them around, but we don't trust a user to be able to do that today. > > It's the combinators that read/write to a Ptr are the dangerous bits, not > pure math. > > -Edward > > > On Wed, Aug 10, 2016 at 10:23 AM, Ryan Newton wrote: > >> Hi Edward, >> >> On Tue, Aug 9, 2016 at 11:58 PM, Edward Kmett wrote: >>> >>> 1.) If you remove IO from being able to be compiled inside Safe code _at >>> all_ most packages I have that bother to expose Safe information will have >>> to stop bothering. >>> >> >> I definitely wouldn't argue for removing it entirely. But it's good to >> know that there are instances where IO functions get mixed up in safe >> modules. I'll try to systematically find all of these on hackage, but in >> the meantime do you have a sample list of modules? >> >> My modest starting proposal is marking certain Foreign.* modules as >> Unsafe rather than Trustworthy. We'll find all the modules affected. But, >> again, are there any modules you know of offhand that are affected? They >> should fall into two categories: >> >> 1. Safe modules that must become Trustworthy (if they import Foreign >> bits, but don't expose the ability to corrupt memory to the clients of >> their APIs). >> 2. Safe modules that must become Unsafe or be split further into >> smaller modules. >> >> Obviously (2) is the biggest source of potential disruption. >> >> I wouldn't ask anyone to accept a patch on GHC until we'd explored these >> impacts pretty thoroughly. >> >> I'd have to cut up too many APIs into too many fine-grained pieces. >>> >> >> Yeah, the module-level business is pretty annoying. "vector' removed >> ".Safe" modules and no one has gotten around to adding the ".Unsafe". >> >> >>> 2.) Assuming instead that you're talking about a stronger-than-Safe >>> additional language extension, say ReallySafe or SafeIO, it all comes down >>> to what the user is allowed to do in IO, doesn't it? What effects are users >>> granted access to? We don't have a very fine-grained system for IO-effect >>> management, and it seems pretty much any choice you pick for what to put in >>> the sandbox will be wrong for some users, so you'd need some sort of pragma >>> for each IO operation saying what bins it falls into and to track that >>> while type checking, etc. >>> >> >> Well, *maybe* it is a slippery slope that leads to a full effect >> system. But I'd like to see these issues enumerated. Does memory safety >> as a goal really involve so many different effects? Do you think there >> will be 1, 3, 10, or 100 things beyond Foreign.Ptr to worry about? >> >> 3.) On the other hand, someone could _build_ an effect system in Haskell >>> that happens to sit on top of IO, holding effects in an HList, undischarged >>> nullary class constraint, etc. >>> >> >> Well, sure, I hope we will continue to aim for this as well. This is >> effectively what we do with our "LVish" Par monad, where we use Safe >> Haskell to ensure users cannot break the effect system in -XSafe code. >> >> Best, >> -Ryan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfdyck at google.com Fri Aug 12 18:05:40 2016 From: mfdyck at google.com (Matthew Farkas-Dyck) Date: Fri, 12 Aug 2016 11:05:40 -0700 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 02/08/2016, Ryan Scott wrote: > * The `builtin` keyword was poorly received. There isn't a obvious > candidate to replace it, and several of us like the word `bespoke`, so > it looks like `bespoke` will be the replacement. (If someone ends up > complaining about it, we've got several other choices.) Alas, i was on vacation when this happened, but i'd like to chime in nonetheless. I'm Anglo-Canadian, and i had to find this word in the dictionary. That said, i haven't found a better alternative, and it's no worse than any other strange word to a newcomer, e.g. Monad. But when i read "bespoke" in adjectival position it makes my English parser go "wat". I read on a few online dictionaries that "bespoken" means about the same; is this so? and if so may we rather use it? From ryan.gl.scott at gmail.com Fri Aug 12 18:31:08 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 12 Aug 2016 14:31:08 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I can understand your reaction to the word "bespoke". I certainly never use it in daily conversation, and it's only from Richard's assurance (and from consulting a dictionary) that I feel confident about using it in this context. I don't think "bespoken" is a synonym for "bespoke", at least according to Merriam-Webster, which claims that the modern-day definition of "bespoke" has a distinct meaning from "bespeak" (which "bespoken" is the past participle of) [1]. Disclaimer: I am not a linguist. :) On the subject of alternative names, you may be interested in reading this section of the DerivingSyntax wiki page [2], which lists other names besides "bespoke" and "builtin" that have been tossed around as ideas. They include: * magic * wiredin * standard * native * original * specialized All of those suggestions sort of convey the meaning I want to evoke (i.e., derive an instance using some domain-specific knowledge to guide the implementation), but they all also have other connotations that could make them sound ambiguous. "Bespoke" at least has the advantage of being an obscure-enough word that I doubt anyone would accuse it of being misleading. I hope you don't interpret this e-mail as dismissing your concerns. It's just that I have to pick _some_ name for this keyword, and after considering all of the options thus far, "bespoke" is the one that seems the most palatable. If folks strongly disagree, please chime in—I'm sure we can figure something that future deriving strategists can stomach. Ryan S. ----- [1] http://www.merriam-webster.com/dictionary/bespoke [2] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax From ekmett at gmail.com Fri Aug 12 18:37:37 2016 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 12 Aug 2016 14:37:37 -0400 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: What about consuming Storable Vectors carefully, or simply working parameterized over vector type, where Storable vectors are one of the options? -Edward On Fri, Aug 12, 2016 at 12:58 PM, Ryan Newton wrote: > Yes, it is peek and poke that are dangerous. It was Foreign.Storable that > I wanted to mark as Unsafe. > > But we do sometimes run into examples where there's an A and a B, and if > you import both, you can make A+B which blows up. So preventing access to > A+B may mean arbitrarily marking one or the other (or both) as Unsafe. > > What I was hoping for examples of are modules you have that are Safe and > import Foreign.Storable. > > > > > On Fri, Aug 12, 2016 at 9:49 AM, Edward Kmett wrote: > >> As for a sample list of modules, let's just start with your very first >> example, Foreign.Ptr: >> >> In and of itself nothing in Foreign.Ptr is unsafe! It allows a bit of >> arithmetic on a type you can't actually use with anything, and provides an >> IO action mixed into an otherwise pure module that happens to create a >> FunPtr slot from a haskell function. In fact this module is a textbook >> example of an otherwise perfectly cromulent Trustworthy module today that >> happens to have a single IO action in it. >> >> I can grab Ptr from it, use its Storable instance to make a default >> signature for other safe code and still be perfectly safe. >> >> It gives no tools for manipulating the contents of the Ptr. It is no more >> dangerous than an Int with a phantom type argument. >> >> You could randomly declare that this module is Unsafe because it combines >> badly with APIs that would be safe if you could rely on any Ptr T actually >> pointing to a T, and that users could then be granted the power to ferry >> them around, but we don't trust a user to be able to do that today. >> >> It's the combinators that read/write to a Ptr are the dangerous bits, not >> pure math. >> >> -Edward >> >> >> On Wed, Aug 10, 2016 at 10:23 AM, Ryan Newton wrote: >> >>> Hi Edward, >>> >>> On Tue, Aug 9, 2016 at 11:58 PM, Edward Kmett wrote: >>>> >>>> 1.) If you remove IO from being able to be compiled inside Safe code >>>> _at all_ most packages I have that bother to expose Safe information will >>>> have to stop bothering. >>>> >>> >>> I definitely wouldn't argue for removing it entirely. But it's good to >>> know that there are instances where IO functions get mixed up in safe >>> modules. I'll try to systematically find all of these on hackage, but in >>> the meantime do you have a sample list of modules? >>> >>> My modest starting proposal is marking certain Foreign.* modules as >>> Unsafe rather than Trustworthy. We'll find all the modules affected. But, >>> again, are there any modules you know of offhand that are affected? They >>> should fall into two categories: >>> >>> 1. Safe modules that must become Trustworthy (if they import Foreign >>> bits, but don't expose the ability to corrupt memory to the clients of >>> their APIs). >>> 2. Safe modules that must become Unsafe or be split further into >>> smaller modules. >>> >>> Obviously (2) is the biggest source of potential disruption. >>> >>> I wouldn't ask anyone to accept a patch on GHC until we'd explored these >>> impacts pretty thoroughly. >>> >>> I'd have to cut up too many APIs into too many fine-grained pieces. >>>> >>> >>> Yeah, the module-level business is pretty annoying. "vector' removed >>> ".Safe" modules and no one has gotten around to adding the ".Unsafe". >>> >>> >>>> 2.) Assuming instead that you're talking about a stronger-than-Safe >>>> additional language extension, say ReallySafe or SafeIO, it all comes down >>>> to what the user is allowed to do in IO, doesn't it? What effects are users >>>> granted access to? We don't have a very fine-grained system for IO-effect >>>> management, and it seems pretty much any choice you pick for what to put in >>>> the sandbox will be wrong for some users, so you'd need some sort of pragma >>>> for each IO operation saying what bins it falls into and to track that >>>> while type checking, etc. >>>> >>> >>> Well, *maybe* it is a slippery slope that leads to a full effect >>> system. But I'd like to see these issues enumerated. Does memory safety >>> as a goal really involve so many different effects? Do you think there >>> will be 1, 3, 10, or 100 things beyond Foreign.Ptr to worry about? >>> >>> 3.) On the other hand, someone could _build_ an effect system in Haskell >>>> that happens to sit on top of IO, holding effects in an HList, undischarged >>>> nullary class constraint, etc. >>>> >>> >>> Well, sure, I hope we will continue to aim for this as well. This is >>> effectively what we do with our "LVish" Par monad, where we use Safe >>> Haskell to ensure users cannot break the effect system in -XSafe code. >>> >>> Best, >>> -Ryan >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Aug 12 21:06:04 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 12 Aug 2016 23:06:04 +0200 Subject: Is Safe Haskell intended to allow segfaults? In-Reply-To: References: Message-ID: On 2016-08-12 20:37, Edward Kmett wrote: > What about consuming Storable Vectors carefully, or simply working > parameterized over vector type, where Storable vectors are one of the > options? > There was actually a great paper about a very similar thing (i.e. "here's the usual interface" vs. "here's how it should be done") recently: http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf It may be of interest -- at least as far as an "improved Ptr/Storable" goes. Cheers, From djsamperi at gmail.com Sat Aug 13 03:55:48 2016 From: djsamperi at gmail.com (Dominick Samperi) Date: Fri, 12 Aug 2016 23:55:48 -0400 Subject: How to force -fPIC on package builds? Message-ID: Hello, I am getting relocation errors when building an executable (specifically, the "H" executable -- part of haskellR) under Fedora Linux, and the message says to "recompile with -fPIC". The FAQ associated with H suggests that I switch to the gold linker (ld.gold) due to bugs in the default linker (ld.bfd), but this only changes the wording of the relocation error messages. I have tried several strategies for satisfying the -fPIC requirement: 1. In cabal files I insert cc-options: and ghc-options: lines including -fPIC 2. To the 'cabal install' command line I add: --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC 3. When building ghc 8.0.1 from source I modify config.mk by including: CONF_CC_OPTS += -fPIC SRC_HSC2HS_OPTS += --cflag=-fPIC CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC [same for STAGE1 and STAGE2] All of this doesn't fix the problem, and the error messages still say "recompile with -fPIC". This may be a bug, but I'm not sure where. Any ideas? Thanks, Dominick From m at tweag.io Sat Aug 13 11:43:44 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Sat, 13 Aug 2016 13:43:44 +0200 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: Hi Dominick, which version of Fedora Linux are you on? The -fPIC message from the linker may well be a red herring. AFAIR generating PIC is the default in GHC, at least for dynamic libraries. Best, -- Mathieu Boespflug Founder at http://tweag.io. On 13 August 2016 at 05:55, Dominick Samperi wrote: > Hello, > > I am getting relocation errors when building an executable > (specifically, the "H" > executable -- part of haskellR) under Fedora Linux, and the message says to > "recompile with -fPIC". > > The FAQ associated with H suggests that I switch to the gold linker > (ld.gold) due to bugs in the default linker (ld.bfd), but this only > changes the wording of the relocation error messages. > > I have tried several strategies for satisfying the -fPIC requirement: > 1. In cabal files I insert cc-options: and ghc-options: lines including > -fPIC > 2. To the 'cabal install' command line I add: > --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC > 3. When building ghc 8.0.1 from source I modify config.mk by including: > CONF_CC_OPTS += -fPIC > SRC_HSC2HS_OPTS += --cflag=-fPIC > CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC > [same for STAGE1 and STAGE2] > > All of this doesn't fix the problem, and the error messages still say > "recompile with -fPIC". > > This may be a bug, but I'm not sure where. Any ideas? > > Thanks, > Dominick > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sat Aug 13 14:22:25 2016 From: djsamperi at gmail.com (Dominick Samperi) Date: Sat, 13 Aug 2016 10:22:25 -0400 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: Hello Mathieu, I'm using Fedora 23. The default Haskell Platform here provides ghc 7.8.4, and this seems to have even more problems. Thus I have been trying to use ghc 8.0.1 compiled from source. I think the red herring bit may apply to 32 bit builds, but I am attempting a 64 bit build. The problem may be related to the way modules are randomly relocated for security reasons, Fedora security policies, and confusion/bugs in the linker(s). Cheers, Dominick On Sat, Aug 13, 2016 at 7:43 AM, Boespflug, Mathieu wrote: > Hi Dominick, > > which version of Fedora Linux are you on? The -fPIC message from the linker > may well be a red herring. AFAIR generating PIC is the default in GHC, at > least for dynamic libraries. > > Best, > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > On 13 August 2016 at 05:55, Dominick Samperi wrote: >> >> Hello, >> >> I am getting relocation errors when building an executable >> (specifically, the "H" >> executable -- part of haskellR) under Fedora Linux, and the message says >> to >> "recompile with -fPIC". >> >> The FAQ associated with H suggests that I switch to the gold linker >> (ld.gold) due to bugs in the default linker (ld.bfd), but this only >> changes the wording of the relocation error messages. >> >> I have tried several strategies for satisfying the -fPIC requirement: >> 1. In cabal files I insert cc-options: and ghc-options: lines including >> -fPIC >> 2. To the 'cabal install' command line I add: >> --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC >> 3. When building ghc 8.0.1 from source I modify config.mk by including: >> CONF_CC_OPTS += -fPIC >> SRC_HSC2HS_OPTS += --cflag=-fPIC >> CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC >> [same for STAGE1 and STAGE2] >> >> All of this doesn't fix the problem, and the error messages still say >> "recompile with -fPIC". >> >> This may be a bug, but I'm not sure where. Any ideas? >> >> Thanks, >> Dominick >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From matthewtpickering at gmail.com Sat Aug 13 16:25:50 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 13 Aug 2016 17:25:50 +0100 Subject: RdrName and decorations In-Reply-To: References: Message-ID: I agree with you Alan. In particular, information about 'pattern' and 'type' keywords should be captured in the AST. It can be scrubbed out in the renamer to avoid polluting later passes. At the moment, the 'type' keyword doesn't do anything to direct the renaming process, it just resolves an ambiguity in parsing. Matt On Fri, Aug 5, 2016 at 2:40 PM, Alan & Kim Zimmerman wrote: > Hi all > > At the moment I am working through ghc-exactprint, adding a feature to add > standard API annotations to any constructed AST so that it can be > (pretty)-printed. > > One of the major headaches is the decorations on a RdrName. > > What I mean by this is that an item appearing in the AST as a RdrName may > have parens or backquotes around it, and may have a preceding keyword out of > [forall, pattern, type]. > > I am slowly teasing out the contextual requirements to determine these, but > it seems that they should be captured directly in the AST already. And not > as API Annotations. > > So the question is, does it make sense to do this? Does it belong in the > OccName or the RdrName if so? > > > Alan > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From matthewtpickering at gmail.com Sat Aug 13 21:42:52 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 13 Aug 2016 22:42:52 +0100 Subject: Harbourmaster is still not building diffs In-Reply-To: <87k2hy71am.fsf@smart-cactus.org> References: <87k2hy71am.fsf@smart-cactus.org> Message-ID: Hello, It has been two months since this email. Could we please talk about reverting to the old phabricator installation to get this working again? Matt On Thu, Jun 9, 2016 at 5:52 PM, Ben Gamari wrote: > Matthew Pickering writes: > >> Since a couple of months ago, harbourmaster no longer builds diffs. >> This is quite a large barrier to entry for new contributors as running >> ./validate takes a long time. > > Hi Matthew, > > Indeed it has been a very long time since Harbormaster has built diffs. > > The story is this: in the past our Harbormaster infrastructure has > been rather brittle due to its reliance on `arc` to apply differentials. > With recently work in Phabricator this fragility can now be addressed, > but at the cost of reworking some of our existing build infrastructure. > Moreover, the new Harbormaster story seems to not have been designed > with a public project such as ours in mind, so there are a few security > issues which need to be worked out (namely it requires a git repository > to which all Phab users can push commits). > > Getting to this point has unfortunately taken significantly longer than > expected to get to this point and it's still not entirely clear how the > new Harbormaster roll-out will work. At this point I suspect we ought to > just roll back to the previous Harbormaster automation script unless there > is a clear path forward with the new infrastructure. > > Austin, what do you think? Can we set a concrete timeline for bringing > Harbormaster back up? > > Cheers, > > - Ben From minesasecret at gmail.com Sun Aug 14 01:40:55 2016 From: minesasecret at gmail.com (Richard Fung) Date: Sat, 13 Aug 2016 18:40:55 -0700 Subject: Help on first ticket In-Reply-To: References: <87vb1ok354.fsf@smart-cactus.org> <7eb267e6aec944a3b07af79d8eb51033@AM3PR30MB019.064d.mgd.msft.net> Message-ID: Hello! Sorry for taking so long on this.. I am still struggling with it and feel like I should probably ask for some assistance or guidance at this point. I think I am beginning to understand the first half of this: making sure that the inlining information is saved regardless of the optimization level. It seems like I need to change the functions that are called from tidyProgram which take the variable omit_prags? However, I am completely lost as to where this inlining takes place.. I have been trying to look at simplifyPgm in SimplCore.hs, but haven't really been able to see where the inlining happens.. Could anyone give me any suggestions? I'm beginning to wonder if I'm in over my head as this is my first time working on a compiler so almost everything is new to me. On the other hand I'm certainly learning a lot along the way. On Tue, Aug 9, 2016 at 8:34 AM, Richard Fung wrote: > > ---------- Forwarded message ---------- > From: Richard Fung > Date: Tue, Aug 9, 2016 at 8:33 AM > Subject: Re: Help on first ticket > To: Simon Peyton Jones > > > It's been a while but I've been able to spend more time on it recently > made some progress. > > I believe I have an idea of what I need to fix in terms of the generating > of ModDetails/ModInfo. First off, please tell me if this is wrong.. it > seems like ModDetails is made in mkBootModDetailsTc and tidyProgram. In > tidyProgram there are several functions which take omit_prags, which I > think is automatically set to True on -O0. These are the things we'll have > to change because they are used in mkIface_ to generate the [IfaceDecl] > used to make ModInfo in addFingerprints. > > Hopefully I'm understanding that part correctly. However, I'm not really > sure how to write a proper test case for this ticket. Also, I think I have > an idea of where to start looking for the place the inlining/unfolding > happens but pointers definitely wouldn't hurt. > > Thanks and sorry this is taking me so long! > > On Fri, Jun 24, 2016 at 12:26 PM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > >> Great. No rush. Yell if you need help. >> >> >> >> Simon >> >> >> >> *From:* Richard Fung [mailto:minesasecret at gmail.com] >> *Sent:* 24 June 2016 19:05 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> >> *Subject:* Re: Help on first ticket >> >> >> >> Hi Simon, I am making progress but slowly (I only have time to work on >> this outside of work unfortunately). >> >> >> >> If this needs to be done soon feel free to reassign it to someone else! >> Otherwise, while at times I feel like I'm over my head I would like to keep >> at it. >> >> >> >> On Fri, Jun 24, 2016 at 4:20 AM, Simon Peyton Jones < >> simonpj at microsoft.com> wrote: >> >> Richard, did you get on ok? >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben >> | Gamari >> | Sent: 04 June 2016 23:20 >> | To: Richard Fung ; ghc-devs at haskell.org >> | Subject: Re: Help on first ticket >> | >> | Richard Fung writes: >> | >> | > Hello! I apologize if this isn't the right place to ask; if it isn't >> | > please steer me in the right direction. >> | > >> | Hi Richard! >> | >> | > Would anyone be willing to advise me on my first ticket? I've been >> | > trying to work on it on and off but haven't made much progress on my >> | own. >> | > >> | > It's ticket #9370: https://ghc.haskell.org/trac/ghc/ticket/9370 >> | > >> | Great, I'm happy to hear that someone has picked this one up. I think >> | it is a nice choice for a self-contained newcomers project. >> | >> | > I think I understand the issue conceptually but I don't know where >> | to >> | > look for the code that needs to be changed.. >> | > >> | I don't know where the code responsible for this is off the top of my >> | head, however I can provide some pointers. >> | >> | So the unfoldings you are looking to preserve come from interface >> | files. >> | The machinery for all of this is in compiler/iface. IfaceSyn.hs is of >> | particular interest and there you will find the definition of >> | IfaceUnfolding, which is the unfolding representation which is stored >> | in the interface file. Unfoldings live inside of IdInfo values, which >> | hold various miscellaneous information which we need to preserve about >> | a particular Id (identifier). >> | >> | There is a somewhat useful comment regarding how IdInfo is treated >> | above the definition of IfaceIdInfo in IfaceSyn. In particular it >> | seems that interface files for modules compiled with -O0 will have >> | their IdInfo fields set to NoInfo. It's not clear what happens when an >> | interface file is read. However, grepping for NoInfo reveals a use- >> | site in TcIface.tcIdInfo which looks interesting (in particular the >> | ignore_prags guard). I think this should be enough to get you going on >> | the interface file part of this. >> | >> | The other part of this ticket is deciding whether to use an unfolding >> | when considering whether to inline. This will be done in the >> | simplifier (compiler/simplCore). Grepping for "inline" and "unfold" in >> | simplCore/Simplify.hs (as well as reading the notes in that file) will >> | likely be enough to get you started. >> | >> | Do let me know if you still feel lost or want to discuss this further. >> | I look forward to hearing how it goes. >> | >> | Cheers, >> | >> | - Ben >> >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h >> | askell.org >> >> %2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com >> >> %7c5ce47a744a1448f >> | ff5cb08d38cc666b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V22RG%2 >> | fAiO1lD5bLCR%2fXz2jv5QCzYAK5HUi6dDaAFQLA%3d >> >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sun Aug 14 04:12:03 2016 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 14 Aug 2016 00:12:03 -0400 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: I should add that H builds and runs nicely under Windows and MacOS (using ghc 8.0.1), so this is indeed a Fedora Linux issue. On Sat, Aug 13, 2016 at 10:22 AM, Dominick Samperi wrote: > Hello Mathieu, > > I'm using Fedora 23. The default Haskell Platform here provides ghc > 7.8.4, and this seems to have even more problems. Thus I have been > trying to use ghc 8.0.1 compiled from source. I think the red herring > bit may apply to 32 bit builds, but I am attempting a 64 bit build. > The problem may be related to the way modules are randomly relocated > for security reasons, Fedora security policies, and confusion/bugs in > the linker(s). > > Cheers, > Dominick > > > On Sat, Aug 13, 2016 at 7:43 AM, Boespflug, Mathieu wrote: >> Hi Dominick, >> >> which version of Fedora Linux are you on? The -fPIC message from the linker >> may well be a red herring. AFAIR generating PIC is the default in GHC, at >> least for dynamic libraries. >> >> Best, >> >> -- >> Mathieu Boespflug >> Founder at http://tweag.io. >> >> On 13 August 2016 at 05:55, Dominick Samperi wrote: >>> >>> Hello, >>> >>> I am getting relocation errors when building an executable >>> (specifically, the "H" >>> executable -- part of haskellR) under Fedora Linux, and the message says >>> to >>> "recompile with -fPIC". >>> >>> The FAQ associated with H suggests that I switch to the gold linker >>> (ld.gold) due to bugs in the default linker (ld.bfd), but this only >>> changes the wording of the relocation error messages. >>> >>> I have tried several strategies for satisfying the -fPIC requirement: >>> 1. In cabal files I insert cc-options: and ghc-options: lines including >>> -fPIC >>> 2. To the 'cabal install' command line I add: >>> --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC >>> 3. When building ghc 8.0.1 from source I modify config.mk by including: >>> CONF_CC_OPTS += -fPIC >>> SRC_HSC2HS_OPTS += --cflag=-fPIC >>> CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC >>> [same for STAGE1 and STAGE2] >>> >>> All of this doesn't fix the problem, and the error messages still say >>> "recompile with -fPIC". >>> >>> This may be a bug, but I'm not sure where. Any ideas? >>> >>> Thanks, >>> Dominick >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> From matthewtpickering at gmail.com Sun Aug 14 10:01:21 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 14 Aug 2016 11:01:21 +0100 Subject: Help on first ticket In-Reply-To: References: <87vb1ok354.fsf@smart-cactus.org> <7eb267e6aec944a3b07af79d8eb51033@AM3PR30MB019.064d.mgd.msft.net> Message-ID: Hello Richard, It is certainly hard work on the first ticket. I spent about an hour this morning trying to find out where the right part to change was and then read Ben's email earlier in this thread which made everything much clearer for me! The essential problem we are trying to solve is: > When a module is compiled with -O0, it does not read unfoldings from modules it imports. Because we reuse the unfolding information across modules (to avoid reloading interface files very often), this unfolding information is then not available in the rest of the compilation pipeline. Simon's suggested fix is 1. Always read in unfoldings, etc, including with -O. (Possible exception: one-shot mode.) 2. Check the -fignore-interface-pragmas flag when considering inlining a function. So for part 1, we need to find the part which deals with *reading in* interface files and seeing where the unfolding information is lost. For part 2, we need to find the part of the optimiser which makes decisions about whether to inline a function. So now I'm re-reading Ben's comment and (as usual) his analysis is spot-on. If you trace the origin of the ignore_prags flag then you'll find it is set by checking whether the option `Opt_IgnoreInterfacePragmas` is set or not. You can find that this flag is automatically set when the opt-level is 0 in DynFlags, I'll leave you to find the exact location! It seems like Simon's suggested fix is removing this guard in loadDecls. It isn't clear to me whether the other information (other than the unfoldings) should still be read in or not. Simon will be able to comment. Now for part 2: I think you should start by looking at the callSiteInline function in coreSyn/CoreUnfold. That will at least get you started looking in the right place. Does that help? Matt On Sun, Aug 14, 2016 at 2:40 AM, Richard Fung wrote: > Hello! Sorry for taking so long on this.. > > I am still struggling with it and feel like I should probably ask for some > assistance or guidance at this point. > > I think I am beginning to understand the first half of this: making sure > that the inlining information is saved regardless of the optimization level. > It seems like I need to change the functions that are called from > tidyProgram which take the variable omit_prags? > > However, I am completely lost as to where this inlining takes place.. I have > been trying to look at simplifyPgm in SimplCore.hs, but haven't really been > able to see where the inlining happens.. > > Could anyone give me any suggestions? I'm beginning to wonder if I'm in over > my head as this is my first time working on a compiler so almost everything > is new to me. On the other hand I'm certainly learning a lot along the way. > > On Tue, Aug 9, 2016 at 8:34 AM, Richard Fung wrote: >> >> >> ---------- Forwarded message ---------- >> From: Richard Fung >> Date: Tue, Aug 9, 2016 at 8:33 AM >> Subject: Re: Help on first ticket >> To: Simon Peyton Jones >> >> >> It's been a while but I've been able to spend more time on it recently >> made some progress. >> >> I believe I have an idea of what I need to fix in terms of the generating >> of ModDetails/ModInfo. First off, please tell me if this is wrong.. it seems >> like ModDetails is made in mkBootModDetailsTc and tidyProgram. In >> tidyProgram there are several functions which take omit_prags, which I think >> is automatically set to True on -O0. These are the things we'll have to >> change because they are used in mkIface_ to generate the [IfaceDecl] used to >> make ModInfo in addFingerprints. >> >> Hopefully I'm understanding that part correctly. However, I'm not really >> sure how to write a proper test case for this ticket. Also, I think I have >> an idea of where to start looking for the place the inlining/unfolding >> happens but pointers definitely wouldn't hurt. >> >> Thanks and sorry this is taking me so long! >> >> On Fri, Jun 24, 2016 at 12:26 PM, Simon Peyton Jones >> wrote: >>> >>> Great. No rush. Yell if you need help. >>> >>> >>> >>> Simon >>> >>> >>> >>> From: Richard Fung [mailto:minesasecret at gmail.com] >>> Sent: 24 June 2016 19:05 >>> To: Simon Peyton Jones >>> Cc: ghc-devs at haskell.org >>> >>> >>> Subject: Re: Help on first ticket >>> >>> >>> >>> Hi Simon, I am making progress but slowly (I only have time to work on >>> this outside of work unfortunately). >>> >>> >>> >>> If this needs to be done soon feel free to reassign it to someone else! >>> Otherwise, while at times I feel like I'm over my head I would like to keep >>> at it. >>> >>> >>> >>> On Fri, Jun 24, 2016 at 4:20 AM, Simon Peyton Jones >>> wrote: >>> >>> Richard, did you get on ok? >>> >>> Simon >>> >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ben >>> | Gamari >>> | Sent: 04 June 2016 23:20 >>> | To: Richard Fung ; ghc-devs at haskell.org >>> | Subject: Re: Help on first ticket >>> | >>> | Richard Fung writes: >>> | >>> | > Hello! I apologize if this isn't the right place to ask; if it isn't >>> | > please steer me in the right direction. >>> | > >>> | Hi Richard! >>> | >>> | > Would anyone be willing to advise me on my first ticket? I've been >>> | > trying to work on it on and off but haven't made much progress on my >>> | own. >>> | > >>> | > It's ticket #9370: https://ghc.haskell.org/trac/ghc/ticket/9370 >>> | > >>> | Great, I'm happy to hear that someone has picked this one up. I think >>> | it is a nice choice for a self-contained newcomers project. >>> | >>> | > I think I understand the issue conceptually but I don't know where >>> | to >>> | > look for the code that needs to be changed.. >>> | > >>> | I don't know where the code responsible for this is off the top of my >>> | head, however I can provide some pointers. >>> | >>> | So the unfoldings you are looking to preserve come from interface >>> | files. >>> | The machinery for all of this is in compiler/iface. IfaceSyn.hs is of >>> | particular interest and there you will find the definition of >>> | IfaceUnfolding, which is the unfolding representation which is stored >>> | in the interface file. Unfoldings live inside of IdInfo values, which >>> | hold various miscellaneous information which we need to preserve about >>> | a particular Id (identifier). >>> | >>> | There is a somewhat useful comment regarding how IdInfo is treated >>> | above the definition of IfaceIdInfo in IfaceSyn. In particular it >>> | seems that interface files for modules compiled with -O0 will have >>> | their IdInfo fields set to NoInfo. It's not clear what happens when an >>> | interface file is read. However, grepping for NoInfo reveals a use- >>> | site in TcIface.tcIdInfo which looks interesting (in particular the >>> | ignore_prags guard). I think this should be enough to get you going on >>> | the interface file part of this. >>> | >>> | The other part of this ticket is deciding whether to use an unfolding >>> | when considering whether to inline. This will be done in the >>> | simplifier (compiler/simplCore). Grepping for "inline" and "unfold" in >>> | simplCore/Simplify.hs (as well as reading the notes in that file) will >>> | likely be enough to get you started. >>> | >>> | Do let me know if you still feel lost or want to discuss this further. >>> | I look forward to hearing how it goes. >>> | >>> | Cheers, >>> | >>> | - Ben >>> >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h >>> | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c5ce47a744a1448f >>> | ff5cb08d38cc666b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V22RG%2 >>> | fAiO1lD5bLCR%2fXz2jv5QCzYAK5HUi6dDaAFQLA%3d >>> >>> >> >> >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From m at tweag.io Sun Aug 14 18:55:48 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Sun, 14 Aug 2016 20:55:48 +0200 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: I was able to reproduce in a docker container and tracked down the source of the issue: https://github.com/tweag/HaskellR/issues/257 The executive summary is that if Cabal is asking hsc2hs to link to a dynamic library, then it should pass --cflag=-fPIC to hsc2hs. Otherwise hsc2hs might fail, because then it might be impossible to link the temporary object files that it creates with the shared library. A workaround is to set "cc-options: -fPIC" in the .cabal file. But in my mind this is probably a Cabal bug. -- Mathieu Boespflug Founder at http://tweag.io. On 14 August 2016 at 06:12, Dominick Samperi wrote: > I should add that H builds and runs nicely under Windows and MacOS > (using ghc 8.0.1), so this is indeed a Fedora Linux issue. > > On Sat, Aug 13, 2016 at 10:22 AM, Dominick Samperi > wrote: > > Hello Mathieu, > > > > I'm using Fedora 23. The default Haskell Platform here provides ghc > > 7.8.4, and this seems to have even more problems. Thus I have been > > trying to use ghc 8.0.1 compiled from source. I think the red herring > > bit may apply to 32 bit builds, but I am attempting a 64 bit build. > > The problem may be related to the way modules are randomly relocated > > for security reasons, Fedora security policies, and confusion/bugs in > > the linker(s). > > > > Cheers, > > Dominick > > > > > > On Sat, Aug 13, 2016 at 7:43 AM, Boespflug, Mathieu wrote: > >> Hi Dominick, > >> > >> which version of Fedora Linux are you on? The -fPIC message from the > linker > >> may well be a red herring. AFAIR generating PIC is the default in GHC, > at > >> least for dynamic libraries. > >> > >> Best, > >> > >> -- > >> Mathieu Boespflug > >> Founder at http://tweag.io. > >> > >> On 13 August 2016 at 05:55, Dominick Samperi > wrote: > >>> > >>> Hello, > >>> > >>> I am getting relocation errors when building an executable > >>> (specifically, the "H" > >>> executable -- part of haskellR) under Fedora Linux, and the message > says > >>> to > >>> "recompile with -fPIC". > >>> > >>> The FAQ associated with H suggests that I switch to the gold linker > >>> (ld.gold) due to bugs in the default linker (ld.bfd), but this only > >>> changes the wording of the relocation error messages. > >>> > >>> I have tried several strategies for satisfying the -fPIC requirement: > >>> 1. In cabal files I insert cc-options: and ghc-options: lines including > >>> -fPIC > >>> 2. To the 'cabal install' command line I add: > >>> --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC > >>> 3. When building ghc 8.0.1 from source I modify config.mk by > including: > >>> CONF_CC_OPTS += -fPIC > >>> SRC_HSC2HS_OPTS += --cflag=-fPIC > >>> CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC > >>> [same for STAGE1 and STAGE2] > >>> > >>> All of this doesn't fix the problem, and the error messages still say > >>> "recompile with -fPIC". > >>> > >>> This may be a bug, but I'm not sure where. Any ideas? > >>> > >>> Thanks, > >>> Dominick > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sun Aug 14 21:49:39 2016 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 14 Aug 2016 17:49:39 -0400 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: Thanks for looking into this Mathieu. I have been using this hsc2hs flag all along, and it has enabled me to build inline-r, but the build of H fails (using ghc-8.0.1). As you mention in your issue tracker, the new twist is to add ghc-options: -dynamic to the cabal file for H (and for any binary that links to inline-r). BTW, how can I compare my results with yours if all I know is that you have used "a docker container"? Wouldn't I need to know what repository and snapshot you are using? On Sun, Aug 14, 2016 at 2:55 PM, Boespflug, Mathieu wrote: > I was able to reproduce in a docker container and tracked down the source of > the issue: https://github.com/tweag/HaskellR/issues/257 > > The executive summary is that if Cabal is asking hsc2hs to link to a dynamic > library, then it should pass --cflag=-fPIC to hsc2hs. Otherwise hsc2hs might > fail, because then it might be impossible to link the temporary object files > that it creates with the shared library. > > A workaround is to set "cc-options: -fPIC" in the .cabal file. But in my > mind this is probably a Cabal bug. > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > On 14 August 2016 at 06:12, Dominick Samperi wrote: >> >> I should add that H builds and runs nicely under Windows and MacOS >> (using ghc 8.0.1), so this is indeed a Fedora Linux issue. >> >> On Sat, Aug 13, 2016 at 10:22 AM, Dominick Samperi >> wrote: >> > Hello Mathieu, >> > >> > I'm using Fedora 23. The default Haskell Platform here provides ghc >> > 7.8.4, and this seems to have even more problems. Thus I have been >> > trying to use ghc 8.0.1 compiled from source. I think the red herring >> > bit may apply to 32 bit builds, but I am attempting a 64 bit build. >> > The problem may be related to the way modules are randomly relocated >> > for security reasons, Fedora security policies, and confusion/bugs in >> > the linker(s). >> > >> > Cheers, >> > Dominick >> > >> > >> > On Sat, Aug 13, 2016 at 7:43 AM, Boespflug, Mathieu wrote: >> >> Hi Dominick, >> >> >> >> which version of Fedora Linux are you on? The -fPIC message from the >> >> linker >> >> may well be a red herring. AFAIR generating PIC is the default in GHC, >> >> at >> >> least for dynamic libraries. >> >> >> >> Best, >> >> >> >> -- >> >> Mathieu Boespflug >> >> Founder at http://tweag.io. >> >> >> >> On 13 August 2016 at 05:55, Dominick Samperi >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> I am getting relocation errors when building an executable >> >>> (specifically, the "H" >> >>> executable -- part of haskellR) under Fedora Linux, and the message >> >>> says >> >>> to >> >>> "recompile with -fPIC". >> >>> >> >>> The FAQ associated with H suggests that I switch to the gold linker >> >>> (ld.gold) due to bugs in the default linker (ld.bfd), but this only >> >>> changes the wording of the relocation error messages. >> >>> >> >>> I have tried several strategies for satisfying the -fPIC requirement: >> >>> 1. In cabal files I insert cc-options: and ghc-options: lines >> >>> including >> >>> -fPIC >> >>> 2. To the 'cabal install' command line I add: >> >>> --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC >> >>> 3. When building ghc 8.0.1 from source I modify config.mk by >> >>> including: >> >>> CONF_CC_OPTS += -fPIC >> >>> SRC_HSC2HS_OPTS += --cflag=-fPIC >> >>> CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC >> >>> [same for STAGE1 and STAGE2] >> >>> >> >>> All of this doesn't fix the problem, and the error messages still say >> >>> "recompile with -fPIC". >> >>> >> >>> This may be a bug, but I'm not sure where. Any ideas? >> >>> >> >>> Thanks, >> >>> Dominick >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> > > From m at tweag.io Mon Aug 15 09:12:30 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 15 Aug 2016 11:12:30 +0200 Subject: How to force -fPIC on package builds? In-Reply-To: References: Message-ID: I've made more explicit how to setup the docker container in the issue tracker: https://github.com/tweag/HaskellR/issues/257#issuecomment-239759880 -- Mathieu Boespflug Founder at http://tweag.io. On 14 August 2016 at 23:49, Dominick Samperi wrote: > Thanks for looking into this Mathieu. I have been using this hsc2hs > flag all along, and it has enabled me to build inline-r, but the build > of H fails (using ghc-8.0.1). As you mention in your issue tracker, > the new twist is to add ghc-options: -dynamic to the cabal file for H > (and for any binary that links to inline-r). > > BTW, how can I compare my results with yours if all I know is that you > have used "a docker container"? Wouldn't I need to know what > repository and snapshot you are using? > > On Sun, Aug 14, 2016 at 2:55 PM, Boespflug, Mathieu wrote: > > I was able to reproduce in a docker container and tracked down the > source of > > the issue: https://github.com/tweag/HaskellR/issues/257 > > > > The executive summary is that if Cabal is asking hsc2hs to link to a > dynamic > > library, then it should pass --cflag=-fPIC to hsc2hs. Otherwise hsc2hs > might > > fail, because then it might be impossible to link the temporary object > files > > that it creates with the shared library. > > > > A workaround is to set "cc-options: -fPIC" in the .cabal file. But in my > > mind this is probably a Cabal bug. > > > > -- > > Mathieu Boespflug > > Founder at http://tweag.io. > > > > On 14 August 2016 at 06:12, Dominick Samperi > wrote: > >> > >> I should add that H builds and runs nicely under Windows and MacOS > >> (using ghc 8.0.1), so this is indeed a Fedora Linux issue. > >> > >> On Sat, Aug 13, 2016 at 10:22 AM, Dominick Samperi > > >> wrote: > >> > Hello Mathieu, > >> > > >> > I'm using Fedora 23. The default Haskell Platform here provides ghc > >> > 7.8.4, and this seems to have even more problems. Thus I have been > >> > trying to use ghc 8.0.1 compiled from source. I think the red herring > >> > bit may apply to 32 bit builds, but I am attempting a 64 bit build. > >> > The problem may be related to the way modules are randomly relocated > >> > for security reasons, Fedora security policies, and confusion/bugs in > >> > the linker(s). > >> > > >> > Cheers, > >> > Dominick > >> > > >> > > >> > On Sat, Aug 13, 2016 at 7:43 AM, Boespflug, Mathieu > wrote: > >> >> Hi Dominick, > >> >> > >> >> which version of Fedora Linux are you on? The -fPIC message from the > >> >> linker > >> >> may well be a red herring. AFAIR generating PIC is the default in > GHC, > >> >> at > >> >> least for dynamic libraries. > >> >> > >> >> Best, > >> >> > >> >> -- > >> >> Mathieu Boespflug > >> >> Founder at http://tweag.io. > >> >> > >> >> On 13 August 2016 at 05:55, Dominick Samperi > >> >> wrote: > >> >>> > >> >>> Hello, > >> >>> > >> >>> I am getting relocation errors when building an executable > >> >>> (specifically, the "H" > >> >>> executable -- part of haskellR) under Fedora Linux, and the message > >> >>> says > >> >>> to > >> >>> "recompile with -fPIC". > >> >>> > >> >>> The FAQ associated with H suggests that I switch to the gold linker > >> >>> (ld.gold) due to bugs in the default linker (ld.bfd), but this only > >> >>> changes the wording of the relocation error messages. > >> >>> > >> >>> I have tried several strategies for satisfying the -fPIC > requirement: > >> >>> 1. In cabal files I insert cc-options: and ghc-options: lines > >> >>> including > >> >>> -fPIC > >> >>> 2. To the 'cabal install' command line I add: > >> >>> --ghc-option=-fPIC --hsc2hs-option=-cflag=-fPIC > >> >>> 3. When building ghc 8.0.1 from source I modify config.mk by > >> >>> including: > >> >>> CONF_CC_OPTS += -fPIC > >> >>> SRC_HSC2HS_OPTS += --cflag=-fPIC > >> >>> CONF_CC_OPTS_STAGE0 = -fno-stack-protector -fPIC > >> >>> [same for STAGE1 and STAGE2] > >> >>> > >> >>> All of this doesn't fix the problem, and the error messages still > say > >> >>> "recompile with -fPIC". > >> >>> > >> >>> This may be a bug, but I'm not sure where. Any ideas? > >> >>> > >> >>> Thanks, > >> >>> Dominick > >> >>> _______________________________________________ > >> >>> ghc-devs mailing list > >> >>> ghc-devs at haskell.org > >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> >> > >> >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Aug 15 18:02:54 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 15 Aug 2016 11:02:54 -0700 Subject: Question about initializing the run-time system Message-ID: Hello, GHC's user guide says that the run-time system cannot re-initialize itself, after it was shut-down (i.e., you can't call `hs_init` after calling `hs_exit`). Could anyone shed some light on why that is? -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfdyck at google.com Mon Aug 15 19:28:37 2016 From: mfdyck at google.com (Matthew Farkas-Dyck) Date: Mon, 15 Aug 2016 12:28:37 -0700 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 12/08/2016, Ryan Scott wrote: > I hope you don't interpret this e-mail as dismissing your concerns. > It's just that I have to pick _some_ name for this keyword, and after > considering all of the options thus far, "bespoke" is the one that > seems the most palatable. Fair enough, like i said, it's not significantly worse than any other nomenclature a newcomer must learn, and i haven't had a better idea ☺ From nicolas.frisby at gmail.com Mon Aug 15 20:04:32 2016 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Mon, 15 Aug 2016 20:04:32 +0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <061.eef289fafdde0c64571d50617d355bf1@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> <061.eef289fafdde0c64571d50617d355bf1@haskell.org> Message-ID: "While were in there", it occurred to me that one `coerce` per constructor argument ideally ought to suffice. On Mon, Aug 15, 2016, 07:17 GHC wrote: > #8516: Add (->) representation and the Invariant class to GHC.Generics > -------------------------------------+------------------------------------- > Reporter: nfrisby | Owner: > Type: feature request | Status: new > Priority: low | Milestone: > Component: Compiler (Type | Version: 7.7 > checker) | > Resolution: | Keywords: Generics > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by RyanGlScott): > > And as it turns out, goldfire has a separate ticket (#8177) for the > proposed idea of being able to give explicit role signatures to type > families, which might make the potential regression in > [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 this comment] not > an actual regression. See my comment > [https://ghc.haskell.org/trac/ghc/ticket/8177#comment:31 here]. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Tue Aug 16 11:08:33 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 16 Aug 2016 16:38:33 +0530 Subject: Behavior of GHC_PACKAGE_PATH Message-ID: Hi, As per the GHC manual (https://downloads.haskell. org/~ghc/master/users-guide/packages.html#the-ghc-package- path-environment-variable), packages which come earlier in the GHC_PACKAGE_PATH supersede the ones which come later. But that does not seem to be the case always. I am dealing with a case where I have multiple versions of a package in different databases. I am passing the list of package dbs via GHC_PACKAGE_PATH and ghc is picking the one which comes later. I expect it to pick the one which comes earlier in the path. In one case the package being picked from a package db which comes later is a newer version which makes me wonder if GHC always prefers a newer version. In another case both the versions are same but still GHC is using the one which come later in the package path. Are there any undocumented factors into play here? None of the packages is broken (as reported by ghc-pkg check). See https://github.com/commercialhaskell/stack/issues/1957#issuecomment- 239655912 for more details on where it is coming from. Thanks, Harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Aug 16 16:28:09 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Aug 2016 16:28:09 +0000 Subject: RdrName and decorations In-Reply-To: References: Message-ID: I think it belongs in the HsSyn syntax tree. The RdrName for (say) Prelude.map is the same RdrName, whether or not it looks like `Prelude.map`. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 05 August 2016 14:40 To: ghc-devs at haskell.org Subject: RdrName and decorations Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName may have parens or backquotes around it, and may have a preceding keyword out of [forall, pattern, type]. I am slowly teasing out the contextual requirements to determine these, but it seems that they should be captured directly in the AST already. And not as API Annotations. So the question is, does it make sense to do this? Does it belong in the OccName or the RdrName if so? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Aug 17 03:26:46 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 16 Aug 2016 20:26:46 -0700 Subject: Question about initializing the run-time system In-Reply-To: References: Message-ID: <1471404298-sup-6343@sabre> I looked at RtsStartup.c but I didn't see any code that was obviously enforcing this (have you tried it?)rts/RtsStartup.c However, at a guess, I bet the reason is related to the reason why we can't have multiple copies of the RTS in the same memory address space: the way we handle CAFs scribbles over data pages that we loaded in from objects. I last looked at this when working on https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced#Method2:copystaticclosuresintoaspecialareaatstartup Edward Excerpts from Iavor Diatchki's message of 2016-08-15 11:02:54 -0700: > Hello, > > GHC's user guide says that the run-time system cannot re-initialize itself, > after it was shut-down (i.e., you can't call `hs_init` after calling > `hs_exit`). > > Could anyone shed some light on why that is? > > -Iavor From matthewtpickering at gmail.com Wed Aug 17 14:16:35 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 17 Aug 2016 15:16:35 +0100 Subject: Broken Build due to T1969 Message-ID: Hi all, https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 broke the build by re-enabling the test T1969 The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 Omer: Is it best to revert this patch and mark the test broken again? Matt From harendra.kumar at gmail.com Wed Aug 17 14:37:35 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 17 Aug 2016 20:07:35 +0530 Subject: ghc command line arguments parsing Message-ID: Hi, ghc accepts a flag and its argument as a single quoted or escaped argument as well. For example all of the following are equivalent: ghc -package foo ghc "-package foo" ghc -package\ foo Is this by design or accidental? This has a nice side effect to make passing ghc arguments via rughc simple. For example runghc "-package foo" or runghc -package\ foo will pass "-package foo" to ghc. The alternative and documented way to achieve the same effect is runghc -package --ghc-arg=foo which is not that convenient. My question is - can we rely on this way of parsing? If it is not by design, does it make sense to legalize and therefore document this? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Aug 17 14:59:32 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 17 Aug 2016 14:59:32 +0000 Subject: Broken Build due to T1969 In-Reply-To: References: Message-ID: Ugh. I validated that patch before committing and validated many times after that patch. Are you using a 32bit system? Maybe we should bump the numbers for 32bit builds too. I'm hesitant to mark the test broken because I'm afraid that the numbers will increase if we stop testing for allocations/residency completely. I think temporarily bumping numbers is better than temporarily disabling it. What are the numbers you're getting? 2016-08-17 14:16 GMT+00:00 Matthew Pickering : > Hi all, > > https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 > > broke the build by re-enabling the test T1969 > > The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 > > Omer: Is it best to revert this patch and mark the test broken again? > > Matt From matthewtpickering at gmail.com Wed Aug 17 15:17:42 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 17 Aug 2016 16:17:42 +0100 Subject: Broken Build due to T1969 In-Reply-To: References: Message-ID: I am just seeing it on harbourmaster. https://phabricator.haskell.org/harbormaster/build/12730/?l=100 Matt On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan wrote: > Ugh. I validated that patch before committing and validated many times after > that patch. Are you using a 32bit system? Maybe we should bump the numbers for > 32bit builds too. > > I'm hesitant to mark the test broken because I'm afraid that the numbers will > increase if we stop testing for allocations/residency completely. I think > temporarily bumping numbers is better than temporarily disabling it. > > What are the numbers you're getting? > > 2016-08-17 14:16 GMT+00:00 Matthew Pickering : >> Hi all, >> >> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 >> >> broke the build by re-enabling the test T1969 >> >> The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 >> >> Omer: Is it best to revert this patch and mark the test broken again? >> >> Matt From omeragacan at gmail.com Wed Aug 17 18:05:37 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 17 Aug 2016 18:05:37 +0000 Subject: Broken Build due to T1969 In-Reply-To: References: Message-ID: Hmm, it seems to be a 64bit Linux. Interestingly peak_megabytes_allocated is also different than numbers I'm getting on my 64bit Linux laptop. Maybe this is because harbormaster is booting with GHC 7.10.3 and I'm booting with GHC 8.0.1. I'm currently validating with 7.10.3 to see if I'll get the same numbers. 2016-08-17 15:17 GMT+00:00 Matthew Pickering : > I am just seeing it on harbourmaster. > > https://phabricator.haskell.org/harbormaster/build/12730/?l=100 > > Matt > > > > On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan wrote: >> Ugh. I validated that patch before committing and validated many times after >> that patch. Are you using a 32bit system? Maybe we should bump the numbers for >> 32bit builds too. >> >> I'm hesitant to mark the test broken because I'm afraid that the numbers will >> increase if we stop testing for allocations/residency completely. I think >> temporarily bumping numbers is better than temporarily disabling it. >> >> What are the numbers you're getting? >> >> 2016-08-17 14:16 GMT+00:00 Matthew Pickering : >>> Hi all, >>> >>> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 >>> >>> broke the build by re-enabling the test T1969 >>> >>> The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 >>> >>> Omer: Is it best to revert this patch and mark the test broken again? >>> >>> Matt From omeragacan at gmail.com Wed Aug 17 18:48:40 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 17 Aug 2016 18:48:40 +0000 Subject: Broken Build due to T1969 In-Reply-To: References: Message-ID: I can't reproduce it on my x86_64 Linux laptop when I boot GHC HEAD with GHC 7.10.2. Anyway, feel free to revert 773e3aad (which disables the test) but I think bumping the numbers a little bit is a better option here as that would at least prevent things from getting worse. I'm curious, does anyone know how much ram harbormaster has? I can't see from the logs how many times GC is running during T1969, but maybe GC is running less number of times which is causing the residency to increase. I'm also wondering if there are more stable ways of testing residency. Can we maybe do something like: runMajorGC >> printResidency In some specific locations in the compiler and only look for those in perf tests? Or does anyone have any better ideas? 2016-08-17 18:05 GMT+00:00 Ömer Sinan Ağacan : > Hmm, it seems to be a 64bit Linux. Interestingly peak_megabytes_allocated is > also different than numbers I'm getting on my 64bit Linux laptop. Maybe this is > because harbormaster is booting with GHC 7.10.3 and I'm booting with GHC 8.0.1. > I'm currently validating with 7.10.3 to see if I'll get the same numbers. > > 2016-08-17 15:17 GMT+00:00 Matthew Pickering : >> I am just seeing it on harbourmaster. >> >> https://phabricator.haskell.org/harbormaster/build/12730/?l=100 >> >> Matt >> >> >> >> On Wed, Aug 17, 2016 at 3:59 PM, Ömer Sinan Ağacan wrote: >>> Ugh. I validated that patch before committing and validated many times after >>> that patch. Are you using a 32bit system? Maybe we should bump the numbers for >>> 32bit builds too. >>> >>> I'm hesitant to mark the test broken because I'm afraid that the numbers will >>> increase if we stop testing for allocations/residency completely. I think >>> temporarily bumping numbers is better than temporarily disabling it. >>> >>> What are the numbers you're getting? >>> >>> 2016-08-17 14:16 GMT+00:00 Matthew Pickering : >>>> Hi all, >>>> >>>> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 >>>> >>>> broke the build by re-enabling the test T1969 >>>> >>>> The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 >>>> >>>> Omer: Is it best to revert this patch and mark the test broken again? >>>> >>>> Matt From ben at smart-cactus.org Wed Aug 17 20:56:25 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 Aug 2016 22:56:25 +0200 Subject: Back from move Message-ID: <877fbfglmu.fsf@smart-cactus.org> Hello everyone! If I have seemed quiet over the last few weeks it is because I was in the middle of a trans-Atlantic move to the United States. Needless to say, I am now somewhat settled again and will be working through my mail backlog over the next day or so. If you have sent something that you'd like a response from me on and I don't reply within the next day don't hesitate to ping me. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Wed Aug 17 21:55:54 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 17 Aug 2016 22:55:54 +0100 Subject: Broken Build due to T1969 In-Reply-To: References: Message-ID: Thanks for checking Omer. I reverted the patch for now and the build is green. I'm not sure about the answers to your other questions, as long as the build stays green then I don't mind :) Matt From rae at cs.brynmawr.edu Thu Aug 18 03:04:36 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 17 Aug 2016 23:04:36 -0400 Subject: Suggesting RankNTypes for ill-formed types In-Reply-To: References: Message-ID: <3F84F40C-C49A-429A-A58E-1FEB5B141F54@cs.brynmawr.edu> I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more helpful to users, even though `ExplicitForAll` is more principled. Richard > On Aug 11, 2016, at 2:45 PM, Oleg Grenrus wrote: > > FWIW. Often when I encounter that error, I want `ScopedTypeVariables`, > yet my code doesn’t always has the scoped type variable used. > So even GHC could parse further and propose it to me, there isn’t anything from to do it :( > > I don’t know if many use /just/ `ExplicitForAll`... > > - Oleg > >> On 11 Aug 2016, at 20:30, Karolina Drobnik > wrote: >> >> Hello everyone, >> >> I am working on my first ticket (#11669, linked below) >> and I have some doubts after a little bit of hacking. >> >> There was a hint that an error message should be >> changed from the one suggesting RankNTypes to ExplicitForall. >> In my opinion it would be quite confusing for the user, especially where >> the type is ill-formed. A plain parse error should be shown here. >> >> It is clear that it should be done in such a way after turning on one >> of the extensions, but what about the situation where proposed >> fix (suggesting RankNTypes/ExplicitForall) won't work? >> We should be able to distinguish ill-formed type from the correct one, >> even before the extension activation. To be honest - I don't know how to do it. >> >> Additionally, I am not sure if we can assume that an user wants >> to use arbitrary rank (which implies ExplicitForall) or just a forall keyword. >> I am for the second one, but it is just my assumption. >> >> And the last minor thing - a type formed in this way also rises an error >> suggesting using RankNTypes (as we know that wouldn't solve the problem): >> >> f :: a. -> Int >> f = undefined >> >> Maybe we could treat it as a typo (simple parse error) and propose >> an extension activation only when forall was parsed earlier? >> That could be tricky. >> >> I'd appreciate some thoughts on this issue because I felt a bit lost >> after digging around the parser. >> >> Best regards, >> >> Karolina >> --------------------------------------------------------- >> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Thu Aug 18 03:13:46 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 17 Aug 2016 23:13:46 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: > On Aug 12, 2016, at 2:31 PM, Ryan Scott wrote: > > I can understand your reaction to the word "bespoke". I certainly > never use it in daily conversation, and it's only from Richard's > assurance (and from consulting a dictionary) that I feel confident > about using it in this context. Oh dear. Please don't take my word for it. I (an American) do not use the word in my native lexicon but instead adopted it after living in England for several years. Would someone who uses this word natively (e.g., someone who has lived in England for more than several years) vouch for this usage? Richard From spam at scientician.net Thu Aug 18 05:34:30 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 18 Aug 2016 07:34:30 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 2016-08-12 20:31, Ryan Scott wrote: > On the subject of alternative names, you may be interested in reading > this section of the DerivingSyntax wiki page [2], which lists other > names besides "bespoke" and "builtin" that have been tossed around as > ideas. They include: > > * magic > * wiredin > * standard > * native > * original > * specialized > Can we please just go with the obvious "builtin"? There's no need for willful obscurity here. Not a native (British) English speaker, but I've consumed a *lot* of UK media over the last ~25-30 years and I can literally only recall having heard "bespoke" used *once* and that was in the term "bespoke suit" where you can sort-of guess its meaning from context. I believe this is also the only context in which it's actually really used in British English. (However, I'll let the native (British) English speakers chime in on that.) Regards, From malcolm.wallace at me.com Thu Aug 18 05:44:45 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 18 Aug 2016 06:44:45 +0100 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <73D87265-8C71-40A9-9C97-EE587FA6B99D@me.com> On 18 Aug 2016, at 06:34, Bardur Arantsson wrote: > Not a native (British) English speaker, but I've consumed a *lot* of UK > media over the last ~25-30 years and I can literally only recall having > heard "bespoke" used *once* and that was in the term "bespoke suit" > where you can sort-of guess its meaning from context. I believe this is > also the only context in which it's actually really used in British > English. (However, I'll let the native (British) English speakers chime > in on that.) "Bespoke" is a reasonably common British English word, used in all of the following phrases: bespoke software bespoke solution bespoke furniture bespoke kitchen bespoke tailoring The meaning is "specially and individually made for this client". The opposite of standard, off-the-shelf, pre-packaged. It implies the outcome was not automatable, even if the individual pieces being assembled were machine-cut. "In the U.S., bespoke software is often called custom or custom-designed software." http://whatis.techtarget.com/definition/bespoke Regards, Malcolm From simonpj at microsoft.com Thu Aug 18 07:30:11 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Aug 2016 07:30:11 +0000 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Personally I like 'bespoke'. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 18 August 2016 04:14 | To: Ryan Scott | Cc: Andres Loeh ; GHC developers | Subject: Re: Request for feedback: deriving strategies syntax | | | > On Aug 12, 2016, at 2:31 PM, Ryan Scott | wrote: | > | > I can understand your reaction to the word "bespoke". I certainly | > never use it in daily conversation, and it's only from Richard's | > assurance (and from consulting a dictionary) that I feel confident | > about using it in this context. | | Oh dear. Please don't take my word for it. I (an American) do not use | the word in my native lexicon but instead adopted it after living in | England for several years. Would someone who uses this word natively | (e.g., someone who has lived in England for more than several years) | vouch for this usage? | | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40microsoft.com%7c89ab823b9cd044d63bc008d3 | c715acff%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gfyq6BECLG97z432 | 0AJH03zGBGi3ETvdA0%2f8uTcm6vA%3d From jan.stolarek at p.lodz.pl Thu Aug 18 11:02:28 2016 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Aug 2016 13:02:28 +0200 Subject: Suggesting RankNTypes for ill-formed types In-Reply-To: <3F84F40C-C49A-429A-A58E-1FEB5B141F54@cs.brynmawr.edu> References: <3F84F40C-C49A-429A-A58E-1FEB5B141F54@cs.brynmawr.edu> Message-ID: <201608181302.28875.jan.stolarek@p.lodz.pl> It doesn't really matter whether we suggest ExplicitForAll, ScopedTypeVariables or RankNTypes. The code in question is plainly wrong and should be a parse error. I skimmed the parser code and I see no easy way of doing this without breaking the fix for #3155 at the same time. What I would try, I think, is to find a different solution to #3155. Janek Dnia czwartek, 18 sierpnia 2016, Richard Eisenberg napisał: > I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more > helpful to users, even though `ExplicitForAll` is more principled. > > Richard > > > On Aug 11, 2016, at 2:45 PM, Oleg Grenrus wrote: > > > > FWIW. Often when I encounter that error, I want `ScopedTypeVariables`, > > yet my code doesn’t always has the scoped type variable used. > > So even GHC could parse further and propose it to me, there isn’t > > anything from to do it :( > > > > I don’t know if many use /just/ `ExplicitForAll`... > > > > - Oleg > > > >> On 11 Aug 2016, at 20:30, Karolina Drobnik >> > wrote: > >> > >> Hello everyone, > >> > >> I am working on my first ticket (#11669, linked below) > >> and I have some doubts after a little bit of hacking. > >> > >> There was a hint that an error message should be > >> changed from the one suggesting RankNTypes to ExplicitForall. > >> In my opinion it would be quite confusing for the user, especially where > >> the type is ill-formed. A plain parse error should be shown here. > >> > >> It is clear that it should be done in such a way after turning on one > >> of the extensions, but what about the situation where proposed > >> fix (suggesting RankNTypes/ExplicitForall) won't work? > >> We should be able to distinguish ill-formed type from the correct one, > >> even before the extension activation. To be honest - I don't know how to > >> do it. > >> > >> Additionally, I am not sure if we can assume that an user wants > >> to use arbitrary rank (which implies ExplicitForall) or just a forall > >> keyword. I am for the second one, but it is just my assumption. > >> > >> And the last minor thing - a type formed in this way also rises an error > >> suggesting using RankNTypes (as we know that wouldn't solve the > >> problem): > >> > >> f :: a. -> Int > >> f = undefined > >> > >> Maybe we could treat it as a typo (simple parse error) and propose > >> an extension activation only when forall was parsed earlier? > >> That could be tricky. > >> > >> I'd appreciate some thoughts on this issue because I felt a bit lost > >> after digging around the parser. > >> > >> Best regards, > >> > >> Karolina > >> --------------------------------------------------------- > >> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- 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. From spam at scientician.net Thu Aug 18 14:33:41 2016 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 18 Aug 2016 16:33:41 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <73D87265-8C71-40A9-9C97-EE587FA6B99D@me.com> References: <9965ce39e1bf4d529bfbffe9f188b631@DB4PR30MB030.064d.mgd.msft.net> <73D87265-8C71-40A9-9C97-EE587FA6B99D@me.com> Message-ID: On 2016-08-18 07:44, Malcolm Wallace wrote: > > On 18 Aug 2016, at 06:34, Bardur Arantsson wrote: > >> Not a native (British) English speaker, but I've consumed a *lot* of UK >> media over the last ~25-30 years and I can literally only recall having >> heard "bespoke" used *once* and that was in the term "bespoke suit" >> where you can sort-of guess its meaning from context. I believe this is >> also the only context in which it's actually really used in British >> English. (However, I'll let the native (British) English speakers chime >> in on that.) > > "Bespoke" is a reasonably common British English word, used in all of the following phrases: > > bespoke software > bespoke solution > bespoke furniture > bespoke kitchen > bespoke tailoring > > The meaning is "specially and individually made for this client". The opposite of standard, off-the-shelf, pre-packaged. It implies the outcome was not automatable, even if the individual pieces being assembled were machine-cut. > Thanks, Mildly interestingly, both the online M-W and the online OED list only the clothing by example. (Though the definitions don't *preclude* any other type of goods.) > "In the U.S., bespoke software is often called custom or custom-designed software." http://whatis.techtarget.com/definition/bespoke > AFAIUI "custom", alas, doesn't really work in this context. :( Anyway, regardless of all that: "bespoke" is still a needlessly obscure word, IMO. Ergonomics matter in programming languages. Regards, From harendra.kumar at gmail.com Thu Aug 18 17:59:06 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 18 Aug 2016 23:29:06 +0530 Subject: ghc command line arguments parsing In-Reply-To: References: Message-ID: On 18 August 2016 at 20:51, Sven Panne wrote: > 2016-08-17 16:37 GMT+02:00 Harendra Kumar : > >> ghc accepts a flag and its argument as a single quoted or escaped >> argument as well. For example all of the following are equivalent: >> >> ghc -package foo >> ghc "-package foo" >> ghc -package\ foo >> >> Is this by design or accidental? >> > > I would call this a bug, probably some missing quoting somewhere: Most > commands I know don't do splitting on the arguments for themselves. Just > try e.g. > > gcc "-v -v" > Initially I too thought the same but then I did some more testing and it turned out that the way ghc does not really parse it exactly in the same way as independent unquoted arguments. It only parses a flag which takes an argument. For example: ghc "-package foo" -- parses foo as an argument to the -package flag ghc "-package foo -v" -- is not the same as "-package foo" and "-v" arguments passed independently, it is "foo -v" as the argument to "-package" So it essentially allows packing a flag and its argument together. Which provides a nice way to pass flags and their values as a single unit. This may be accidental to begin with but I liked this just because it makes passing opaque flags combined with arguments from a wrapper program like runghc much more convenient. I cannot think of any downside of this behavior unless someone points out otherwise. > >> This has a nice side effect to make passing ghc arguments via rughc >> simple. For example runghc "-package foo" or runghc -package\ foo will pass >> "-package foo" to ghc. The alternative and documented way to achieve the >> same effect is runghc -package --ghc-arg=foo which is not that convenient. >> >> My question is - can we rely on this way of parsing? If it is not by >> design, does it make sense to legalize and therefore document this? >> > > And my question is: Can we fix this bug? :-D If this is not considered a > bug, we should be very explicit about this deviation from standard behavior > in the documentation, including the reasons for it. > As I explained above, I would prefer to keep this bug :-) and document it especially for runghc as a better alternative to --ghc-arg=foo . So instead of saying: runghc -package --ghc-arg=text -package --ghc-arg=turtle hello.hs We can just say: runghc "-package text" "-package turtle" hello.hs -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Thu Aug 18 18:46:16 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 18 Aug 2016 14:46:16 -0400 Subject: Request for feedback: deriving strategies syntax Message-ID: Bardur, Since you don't like "bespoke", would you mind suggesting an alternative, or advocating for a previously mentioned idea? From [1], the ideas I've seen tossed around are: * builtin * standard (Elliot Cameron suggested it here [2]) * wiredin (Cater Schonwald suggested it here [3]) * magic (Andres Löh suggested it here [4]) * native * original * specialized (the above three are ad hoc suggestions I came up with in a hurry) Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html From matthewtpickering at gmail.com Thu Aug 18 19:19:46 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 18 Aug 2016 20:19:46 +0100 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: I also like 'bespoke' but then it seems to be a much more common in British English than American English. On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott wrote: > Bardur, > > Since you don't like "bespoke", would you mind suggesting an > alternative, or advocating for a previously mentioned idea? From [1], > the ideas I've seen tossed around are: > > * builtin > * standard (Elliot Cameron suggested it here [2]) > * wiredin (Cater Schonwald suggested it here [3]) > * magic (Andres Löh suggested it here [4]) > * native > * original > * specialized (the above three are ad hoc suggestions I came up with in a hurry) > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From eacameron at gmail.com Thu Aug 18 19:23:51 2016 From: eacameron at gmail.com (Elliot Cameron) Date: Thu, 18 Aug 2016 15:23:51 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: Given the prevalence of spellings like "normalise" in common Haskell packages, we might just be settling on British English. Being American makes that a tad difficult on my end, but personally I can make peace with it. On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > I also like 'bespoke' but then it seems to be a much more common in > British English than American English. > > On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott > wrote: > > Bardur, > > > > Since you don't like "bespoke", would you mind suggesting an > > alternative, or advocating for a previously mentioned idea? From [1], > > the ideas I've seen tossed around are: > > > > * builtin > > * standard (Elliot Cameron suggested it here [2]) > > * wiredin (Cater Schonwald suggested it here [3]) > > * magic (Andres Löh suggested it here [4]) > > * native > > * original > > * specialized (the above three are ad hoc suggestions I came up with in > a hurry) > > > > Ryan S. > > ----- > > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/ > DerivingStrategies#Alternativesyntax > > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html > > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html > > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.frisby at gmail.com Thu Aug 18 20:00:16 2016 From: nicolas.frisby at gmail.com (Nicolas Frisby) Date: Thu, 18 Aug 2016 20:00:16 +0000 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: The Report specifies the semantics of most (all other than Generic?) derivation strategies that are baked-in to the compiler. https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011 I think this raises an issue of what *exactly* we are currently referring to as "bespoke". E.G. can it vary with the precise compiler being used? (Maybe your wiki page addresses this; I haven't clicked through.) But maybe "language-report" would supplant "bespoke". And perhaps "GHC-7.8" would also make sense, if the baked-in derivation scheme varies from the report's spec? Etc. HTH. -Nick On Thu, Aug 18, 2016, 12:24 Elliot Cameron wrote: > Given the prevalence of spellings like "normalise" in common Haskell > packages, we might just be settling on British English. Being American > makes that a tad difficult on my end, but personally I can make peace with > it. > > On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > >> I also like 'bespoke' but then it seems to be a much more common in >> British English than American English. >> >> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott >> wrote: >> > Bardur, >> > >> > Since you don't like "bespoke", would you mind suggesting an >> > alternative, or advocating for a previously mentioned idea? From [1], >> > the ideas I've seen tossed around are: >> > >> > * builtin >> > * standard (Elliot Cameron suggested it here [2]) >> > * wiredin (Cater Schonwald suggested it here [3]) >> > * magic (Andres Löh suggested it here [4]) >> > * native >> > * original >> > * specialized (the above three are ad hoc suggestions I came up with in >> a hurry) >> > >> > Ryan S. >> > ----- >> > [1] >> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies#Alternativesyntax >> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html >> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html >> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldurpet at gmail.com Fri Aug 19 01:45:00 2016 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Fri, 19 Aug 2016 01:45:00 +0000 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: I haven't followed the thread but do we actually need a name for it, can't it be indicated by omission? ‘default’ or ‘builtin’ sounds okay 2016-08-18 20:00 GMT+00:00 Nicolas Frisby : > The Report specifies the semantics of most (all other than Generic?) > derivation strategies that are baked-in to the compiler. > > https://www.haskell.org/onlinereport/haskell2010/ > haskellch11.html#x18-18200011 > > I think this raises an issue of what *exactly* we are currently referring > to as "bespoke". E.G. can it vary with the precise compiler being used? > (Maybe your wiki page addresses this; I haven't clicked through.) > > But maybe "language-report" would supplant "bespoke". And perhaps > "GHC-7.8" would also make sense, if the baked-in derivation scheme varies > from the report's spec? Etc. > > HTH. -Nick > > On Thu, Aug 18, 2016, 12:24 Elliot Cameron wrote: > >> Given the prevalence of spellings like "normalise" in common Haskell >> packages, we might just be settling on British English. Being American >> makes that a tad difficult on my end, but personally I can make peace with >> it. >> >> On Thu, Aug 18, 2016 at 3:19 PM, Matthew Pickering < >> matthewtpickering at gmail.com> wrote: >> >>> I also like 'bespoke' but then it seems to be a much more common in >>> British English than American English. >>> >>> On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott >>> wrote: >>> > Bardur, >>> > >>> > Since you don't like "bespoke", would you mind suggesting an >>> > alternative, or advocating for a previously mentioned idea? From [1], >>> > the ideas I've seen tossed around are: >>> > >>> > * builtin >>> > * standard (Elliot Cameron suggested it here [2]) >>> > * wiredin (Cater Schonwald suggested it here [3]) >>> > * magic (Andres Löh suggested it here [4]) >>> > * native >>> > * original >>> > * specialized (the above three are ad hoc suggestions I came up with >>> in a hurry) >>> > >>> > Ryan S. >>> > ----- >>> > [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/ >>> DerivingStrategies#Alternativesyntax >>> > [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html >>> > [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html >>> > [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html >>> > _______________________________________________ >>> > ghc-devs mailing list >>> > ghc-devs at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Aug 19 01:51:25 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Aug 2016 03:51:25 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: On 2016-08-18 20:46, Ryan Scott wrote: > Bardur, > > Since you don't like "bespoke", would you mind suggesting an > alternative, or advocating for a previously mentioned idea? From [1], > the ideas I've seen tossed around are: > > * builtin > * standard (Elliot Cameron suggested it here [2]) > * wiredin (Cater Schonwald suggested it here [3]) > * magic (Andres Löh suggested it here [4]) > * native > * original > * specialized (the above three are ad hoc suggestions I came up with in a hurry) (I think I did suggest 'builtin', but it was buried in a sentence, so it was easy to miss.) Honestly, I don't care particularly much which exact word it becomes just as long at isn't some 'cute' or obscurse[1] word. 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in the latter. Of the remaining alternatives I like 'builtin' and 'standard' the best, simply because they're common and not all that overloaded when it comes to their meaning in programming languages. Regards, From spam at scientician.net Fri Aug 19 04:52:27 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Aug 2016 06:52:27 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: On 2016-08-19 03:45, Baldur Blöndal wrote: > I haven't followed the thread but do we actually need a name for it, > can't it be indicated by omission? > ‘default’ or ‘builtin’ sounds okay 'default' is good too, IMO. From monkleyon at googlemail.com Fri Aug 19 06:34:30 2016 From: monkleyon at googlemail.com (monkleyon at googlemail.com) Date: Fri, 19 Aug 2016 08:34:30 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: Message-ID: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> > Honestly, I don't care particularly much which exact word it becomes > just as long at isn't some 'cute' or obscurse[1] word. > > 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in > the latter. I'm native German. I never was in any English-speaking country in my life. Almost all my English media is from the USA. I'm not a tailor. Yet "bespoke" was familiar and instantly tells me what's important. So I may just be one point on the map, but I am not sure your argument that it is "obscure" is valid, sorry. That being said, let me add a package of "awwww"s for all the times an English native complains that he has to learn a new word to program. Take a portion and pass it along, would you? ;) Apropos learning words: while searching for information if "bespoke" is really obscure (I found none in either direction) I stumbled upon some (I think) not-yet-mentioned possible options * custom(i[zs]ed)? * tailored * idiosyncratic (uh, yeah!) Yet my vote is with "bespoke". Short, informative, recognizable, and a nice balance of quirky and reasonable, just like so much else here. Cheers, MarLinn From svenpanne at gmail.com Fri Aug 19 07:01:02 2016 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 19 Aug 2016 09:01:02 +0200 Subject: ghc command line arguments parsing In-Reply-To: References: Message-ID: 2016-08-18 19:59 GMT+02:00 Harendra Kumar : > [...] It only parses a flag which takes an argument. [...] > o_O AFAICT, this is even more non-standard and quite surprising... > As I explained above, I would prefer to keep this bug :-) and document it > especially for runghc as a better alternative to --ghc-arg=foo . [...] > While I partly understand your motivation, convenience is often the worst reason for doing something. Consistency is IMHO infinitely more valuable than having various inconsistent ad-hoc "convenient" shortcuts here and there. If you look around the tool landscape, commandline argument parsing is already less consistent than it should be (try e.g. ps/tar/unzip/df/java/git/...), and I don't think we should make this situation worse by adding yet another variation. As long as we have a way to pass arguments down the pipeline (as we obviously have), thing are fine IMHO. This situation is not much different from the common -Wl,foo option for GCC and friends to pass arguments to the linker. And to be honest: How often do you really *type* long commandlines compared to putting them into some kind of script? Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Fri Aug 19 07:15:24 2016 From: rf at rufflewind.com (Phil Ruffwind) Date: Fri, 19 Aug 2016 03:15:24 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> References: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> Message-ID: <1471590924.1454632.699880921.3639E4A0@webmail.messagingengine.com> I would prefer "custom" simply because the word is used often enough in computing that there is no chance of someone having to pull out a dictionary for it. From spam at scientician.net Fri Aug 19 07:18:03 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Aug 2016 09:18:03 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> References: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> Message-ID: On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote: >> Honestly, I don't care particularly much which exact word it becomes >> just as long at isn't some 'cute' or obscurse[1] word. >> >> 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in >> the latter. > I'm native German. I never was in any English-speaking country in my > life. Almost all my English media is from the USA. I'm not a tailor. Yet > "bespoke" was familiar and instantly tells me what's important. > So I may just be one point on the map, but I am not sure your argument > that it is "obscure" is valid, sorry. > > That being said, let me add a package of "awwww"s for all the times an > English native complains that he has to learn a new word to program. > Take a portion and pass it along, would you? ;) > > Apropos learning words: while searching for information if "bespoke" is > really obscure (I found none in either direction) I stumbled upon some > (I think) not-yet-mentioned possible options > I said it was *needlessly* obscure. There's absolutely no reason to choose such a word in this case. > * custom(i[zs]ed)? This seems to convey the exact opposite when used in the programming domain. When I 'customize' something or specify a 'custom' $something, I expect that I, the programmer, am going to provide the logic/behavior/whatever. > * tailored Just as 'bad' as bespoke -- and still has a sort of feeling of 'customized'. Bespoke at least has the very strong connotation of "getting someone else to do it for you" whereas tailored doesn't *quite* have that. (All, IMO, of course.) Regards, From spam at scientician.net Fri Aug 19 07:22:25 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 19 Aug 2016 09:22:25 +0200 Subject: Request for feedback: deriving strategies syntax In-Reply-To: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> References: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> Message-ID: (Sorry if anybody receives this twice, I think I flubbed my 'send'.) On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote: > Yet my vote is with "bespoke". Short, informative, recognizable, and a > nice balance of quirky and reasonable, just like so much else here. > ... oh, and might I submit the opinion that quirky is not a quality that to be desired of a programming language, even if it's only a keyword? (Anyway, I think I'll stop here. This is too much opinion for any further discussion to be useful.) Regards, From harendra.kumar at gmail.com Fri Aug 19 08:58:34 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 19 Aug 2016 14:28:34 +0530 Subject: ghc command line arguments parsing In-Reply-To: References: Message-ID: On 19 August 2016 at 12:31, Sven Panne wrote: > 2016-08-18 19:59 GMT+02:00 Harendra Kumar : > >> [...] It only parses a flag which takes an argument. [...] >> > > o_O AFAICT, this is even more non-standard and quite surprising... > > >> As I explained above, I would prefer to keep this bug :-) and document it >> especially for runghc as a better alternative to --ghc-arg=foo . [...] >> > > While I partly understand your motivation, convenience is often the worst > reason for doing something. Consistency is IMHO infinitely more valuable > than having various inconsistent ad-hoc "convenient" shortcuts here and > there. If you look around the tool landscape, commandline argument parsing > is already less consistent than it should be (try e.g. > ps/tar/unzip/df/java/git/...), and I don't think we should make this > situation worse by adding yet another variation. > > As long as we have a way to pass arguments down the pipeline (as we > obviously have), thing are fine IMHO. This situation is not much different > from the common -Wl,foo option for GCC and friends to pass arguments to the > linker. And to be honest: How often do you really *type* long commandlines > compared to putting them into some kind of script? > Funnily consistency was my point too and not convenience. I totally agree that consistency is more important. The end objective is less referring to manuals and rely more on intuition and consistency. Its all about making it easier to remember and not about typing less or more. But what I find consistent you find it inconsistent :-) Maybe I am squinting too much to see it that way. Let me explain it a bit. I see each flag as a single unit including its argument. In fact command line tools often combine the flag and value e.g. -f/path/to/ghc and -f /path/to/ghc mean the same thing to runghc. This is usually done for a single character flag only because it is unambiguous to parse even with using a space separator. If we generalize this we can also allow a space in the combined value if escaped e.g. -package foo and "-package foo" can be considered the same thing. If we look at flags in this way they in fact look more consistent - everything i.e. all flags start with a dash. In fact I discovered that it works this way because I intuitively guessed it, runghc CLI help did not have any mention of how to pass such args to ghc. I discovered '--ghc-arg=' only later in users guide. I would be happier with a gcc style -Wl,foo or -Xlinker way because it is more consistent compared to how runghc passes options to ghc. runghc has two ways of handling ghc options. Options starting with a dash are passed even without having to use '--ghc-arg=' and if they conflict with runghc options then we use '--' to separate the two. If a ghc option does not start with a dash then we use '--ghc-arg'. Three different ways! too complicated to remember or think about. As you said I would be happier with an inconvenient to type but consistent alternative where we use '--ghc-arg=' for everything and get rid of the other ways. Originally I was trying to do it the other way round by getting rid of '--ghc-arg' instead. But this perhaps sounds easier to think about. Let me know what you think. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Aug 19 09:12:35 2016 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 19 Aug 2016 11:12:35 +0200 Subject: ghc command line arguments parsing In-Reply-To: References: Message-ID: 2016-08-19 10:58 GMT+02:00 Harendra Kumar : > Funnily consistency was my point too and not convenience. I totally agree > that consistency is more important. The end objective is less referring to > manuals and rely more on intuition and consistency. Its all about making it > easier to remember and not about typing less or more. [...] > OK, then I probably misunderstood you and we're actually in the same boat... :-) > [...] As you said I would be happier with an inconvenient to type but > consistent alternative where we use '--ghc-arg=' for everything and get rid > of the other ways. [...] > Hmmm, do we need '--ghc-args=' at all when we have '--' as the border between the 2 "argument worlds"? Without thinking too much about it, :-} I guess we don't. This would be consistent with how e.g. "stack exec" or "gdb" work. An explicit option --pass-this-to-some-progXY is only needed when there are more than 2 "argument worlds" involved, otherwise '--' is enough, and also easier to type/remember. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Aug 19 09:38:53 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 19 Aug 2016 09:38:53 +0000 Subject: Landing Backpack in HEAD In-Reply-To: <1470942422-sup-8643@sabre> References: <1470942422-sup-8643@sabre> Message-ID: I'm supportive of doing this, and am working with Edward on it. Yell if you object. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Edward Z. Yang | Sent: 11 August 2016 20:07 | To: ghc-devs | Subject: Landing Backpack in HEAD | | Hello friends, | | I'm hoping to land Backpack (the patch is two years in the making | now!) for GHC 8.2, even though 8.2 is intended to be a stabilization | and performance release. In this email, I will make the case that the | Backpack patch is relatively self-contained and will not affect non- | Backpack users, and explain how you might be affected by the patch. | The most recent patchset can be found at | https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The | Backpack patch" in the commit log, since I plan on squashing these | commits before committing. | | OK, here is what is in the patchset that affects non-Backpack users: | | - The primary, overarching change is that there is now | a distinction between "semantic" and "identity" modules. | This solves a problem with hsig files: suppose | you have A.hsig which defines data T in package p. | The resulting A.hi is most accurately identified | as p[A=]:A; however, the Name for T should be .T, | not p[A=]:A.T. The former is an identity module | (it *identifies* interfaces), whereas the latter is a semantic | module (it is what is used in names). Without Backpack, | these two identities are always the same. There are a number | of places in the existing codepaths where we have to | distinguish between the two concepts (sometimes you | want semantic, sometimes you want identity); we DEFAULT | to the identity module but I fix a few cases where | semantic modules were desired instead. | | - UnitId is generalized to also record how a component | is instantiated (a mapping from module names to modules.) | Without Backpack this is blank and equivalent to the | existing UnitId. | | - Packages has been refactored to also handle Backpack `-unit-id` | flags, since we have to do some extra work to determine | what inherited signatures merge where. | | - The patch REVERTS all of the old support we had for hsig | files; -sig-of is no more. spinda had mentioned that | Liquid Haskell used this in some cases, and I'm looking | at supporting *just* their particular use-case. | | - A new driver mode --backpack, which process test.bkp files. | This mode is used PURELY for testing, and end users | are not supposed to use it. These all live in their own | modules (BkpSyn, DriverBkp) except for some modest, | convenient extensions to the lexer and parser to parse | multiple modules at once. | | The patch also comes with rewritten typechecking support for hsig | files, and instantiating indefinite packages on the fly, but these are | all standalone pieces of functionality which are not tied to any | existing compiler infrastructure. | | Thanks, | Edward | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=02%7c01%7csimonpj%40microsoft.com%7c53ecc3a967e94989c6ea08d3 | c21aba4a%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c6360653924505858 | 34&sdata=M9gGg0DYYyLgiETs8bYGuxLlU7uVDJweyo5NeJB2bDM%3d From harendra.kumar at gmail.com Fri Aug 19 12:06:23 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 19 Aug 2016 17:36:23 +0530 Subject: ghc command line arguments parsing In-Reply-To: References: Message-ID: On 19 August 2016 at 14:42, Sven Panne wrote: > > Hmmm, do we need '--ghc-args=' at all when we have '--' as the border > between the 2 "argument worlds"? Without thinking too much about it, :-} I > guess we don't. This would be consistent with how e.g. "stack exec" or > "gdb" work. An explicit option --pass-this-to-some-progXY is only needed > when there are more than 2 "argument worlds" involved, otherwise '--' is > enough, and also easier to type/remember. > Hmm, I have been there :-) There is a slight gotcha here. This is how the runghc command looks like: runghc [runghc flags] [--] [GHC flags] progname [prog args] The regular '--' separation works well when we have only two worlds; we consume upto '--' and give the rest opaquely to the other one. Here we have three scopes, we need to separate runghc flags, GHC flags, program and its args. In the above command we cannot distinguish a GHC arg from progname. One way to solve that is to put another mandatory '--' after the GHC flags so that GHC flags are always delimited. With that here are the valid forms of the command: 1) runghc [runghc flags] progname [prog args] 2) runghc [runghc flags] -- progname [prog args] 3) runghc [runghc flags] -- [GHC flags] -- progname [prog args] For simplicity we will only pass GHC args using the 3rd form of the command even if they are not conflicting with runghc flags. Note that these changes will be incompatible with the previous implementation. Does this sound ok? Or we keep the good old '--ghc-arg='? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Aug 19 18:40:06 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 19 Aug 2016 20:40:06 +0200 Subject: vectorisation code? In-Reply-To: <87wpn04jon.fsf@smart-cactus.org> References: <54C039D0.4020206@apeiron.net> <6AA9EDDD-2444-4ADE-8675-793745BBA374@cse.unsw.edu.au> <618BE556AADD624C9C918AA5D5911BEF562AF251@DB3PRD3001MB020.064d.mgd.msft.net> <54C10257.5030907@apeiron.net> <87twziq0fo.fsf@gmail.com> <54C11F26.9080201@apeiron.net> <87io2lg3x4.fsf@smart-cactus.org> <56A239DF.4070006@apeiron.net> <20160122145759.GA7974@apeiron.net> <3541c1a536d24f5794e432150833b428@DB4PR30MB030.064d.mgd.msft.net> <56A25776.20403@apeiron.net> <878u3ce0nr.fsf@smart-cactus.org> <56A7A7AD.6030105@apeiron.net> <874ma462cc.fsf@smart-cactus.org> <5733542E.4030509@apeiron.net> <87wpn04jon.fsf@smart-cactus.org> Message-ID: <877fbcr4ah.fsf@smart-cactus.org> Ben Gamari writes: > Geoffrey Mainland writes: > >> Hi Ben, >> Hi Geoff, >> Progress is stalled on a rewrite of DPH's use of TH since TH is no >> longer available in stage1. There is no reason this can't be worked >> around, just that it's more work than I initially expected. >> > Alright, thanks for the update Geoff! > Any news on this front? 8.2 isn't imminent but it's certainly on the horizon so it would be good to get this taken care of in the next month or so. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From harendra.kumar at gmail.com Sat Aug 20 18:27:56 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 20 Aug 2016 23:57:56 +0530 Subject: Using stringize and string concatenation in ghc preprocessing Message-ID: Hi, To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. Since ghc passes '-traditional' to the preprocessor which disables these features I thought I can pass my own flags to the preprocessor like this: {-# OPTIONS_GHC -optP -E -optP -undef #-} But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that? Is there any other better way to achieve this? What is the standard way of doing this if any? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 20 18:33:08 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 20 Aug 2016 14:33:08 -0400 Subject: Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar wrote: > But "-optP" seems to only append to the flags that GHC already passes and > gcc has no "-no-traditional" option to undo the effect of the > "-traditional" that GHC has already passed. I think "-optP" should override > the flags passed by ghc rather than appending to them. Is there a reason > not to do that? > > Is there any other better way to achieve this? What is the standard way of > doing this if any? > Removing -traditional will break much Haskell source. Go look at the history of clang with ghc (clang doesn't do -traditional) to see what happens. (tl;dr: without -traditional, cpp knows too much about what constitutes valid C, and mangles and/or throws errors on valid Haskell that doesn't lex the way C does.) You might want to look at cpphs as an alternative preprocessor. There are some ancient K&R-era hacks that could be used if absolutely necessary, but cpphs should be a much simpler and cleaner solution. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak3ntev at gmail.com Sat Aug 20 19:14:40 2016 From: ak3ntev at gmail.com (Eugene Akentyev) Date: Sat, 20 Aug 2016 22:14:40 +0300 Subject: GHC-related project for undergraduate thesis Message-ID: (forwarded from haskell-cafe) Hello, I am an undergraduate student and would like to do something useful for GHC as undergraduate thesis. This list https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions is outdated (last modified 6 years ago) and some projects are already done (?). Do you have any ideas/projects? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sat Aug 20 19:56:10 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 20 Aug 2016 20:56:10 +0100 Subject: GHC-related project for undergraduate thesis In-Reply-To: References: Message-ID: Hello Eugene, Thanks for the patches you have already submitted recently! Which areas of GHC are you interested in working on? GHC is a large project so if you could give us some idea it would be helpful to narrow it down a bit. Matt On Sat, Aug 20, 2016 at 8:14 PM, Eugene Akentyev wrote: > (forwarded from haskell-cafe) > > Hello, > > I am an undergraduate student and would like to do something useful for GHC > as undergraduate thesis. > > This list https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions is > outdated (last modified 6 years ago) and some projects are already done (?). > > Do you have any ideas/projects? > > Thanks. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From m at tweag.io Sun Aug 21 20:31:37 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Sun, 21 Aug 2016 22:31:37 +0200 Subject: Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: Hi Harendra, I ran into this very problem recently. Turns out -traditional knows string concatenation too. I seem to remember learning this by browsing the GHC source code, but now I can't find any occurrence of this pattern. But here's an example of how to do string concatenation with CPP in -traditional mode: https://github.com/tweag/sparkle/blob/a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/Foreign/JNI.hs#L274 . HTH, -- Mathieu Boespflug Founder at http://tweag.io. On 20 August 2016 at 20:33, Brandon Allbery wrote: > On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar > wrote: > >> But "-optP" seems to only append to the flags that GHC already passes and >> gcc has no "-no-traditional" option to undo the effect of the >> "-traditional" that GHC has already passed. I think "-optP" should override >> the flags passed by ghc rather than appending to them. Is there a reason >> not to do that? >> >> Is there any other better way to achieve this? What is the standard way >> of doing this if any? >> > > Removing -traditional will break much Haskell source. Go look at the > history of clang with ghc (clang doesn't do -traditional) to see what > happens. (tl;dr: without -traditional, cpp knows too much about what > constitutes valid C, and mangles and/or throws errors on valid Haskell that > doesn't lex the way C does.) > > You might want to look at cpphs as an alternative preprocessor. There are > some ancient K&R-era hacks that could be used if absolutely necessary, but > cpphs should be a much simpler and cleaner solution. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Aug 21 20:52:21 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 21 Aug 2016 16:52:21 -0400 Subject: Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: On Sun, Aug 21, 2016 at 4:31 PM, Boespflug, Mathieu wrote: > I ran into this very problem recently. Turns out -traditional knows string > concatenation too. I seem to remember learning this by browsing the GHC > source code, but now I can't find any occurrence of this pattern. But > here's an example of how to do string concatenation with CPP in > -traditional mode: https://github.com/tweag/sparkle/blob/ > a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/ > Foreign/JNI.hs#L274 > > . > That's the hacky K&R way I mentioned earlier. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Mon Aug 22 05:11:21 2016 From: tkn.akio at gmail.com (Akio Takano) Date: Mon, 22 Aug 2016 05:11:21 +0000 Subject: Moving ArgumentsDo forward In-Reply-To: References: Message-ID: I have put up an implementation: https://github.com/takano-akio/ghc/commits/argumentdo Shall I submit the patch on the Phabricator, or should this go through the new proposal submission process? Regards, Takano Akio On 4 July 2016 at 07:50, Akio Takano wrote: > Hi Simon, > > I'm sorry about the late reply. > > On 2 June 2016 at 07:19, Simon Peyton Jones wrote: >> Akio >> >> Thanks for bringing back the ArgumentsDo question. >> >> My personal take on it is similar to Bardur: >> >>> AFAICT at best it's a *very* small improvement[1] and fractures >>> Haskell syntax even more around extensions -- tooling etc. will need >>> to understand even *more* syntax extensions[2]. >> >> The benefit to me seems slight. The cost is also modest, but it is not zero (see below), even given a complete implementation. ANY feature carries a cost that is borne by every subsequent implementor, in perpetuity. > > I understand your concern. I think this extension is worthwhile, but > of course this should be ultimately decided on by people who actually > maintain GHC. > >> >> So I am a bit reluctant. >> >> These things are a judgement call, and we don't have a good process for making that decision. A few of us have been talking about putting forward a better process; it'll be a few weeks. >> >> Meanwhile, what to do about ArgumentDo? You say >> >> | I disagree that this is a small improvement, but I don't intend to >> | debate this here. As you said, nothing has really changed since it was >> | discussed before, and a lot of reasons for implementing this extension >> | have been already pointed out. I don't have anything to add. >> >> Is there a wiki page that describes the proposal, and lists the "lot of reasons" why it would be a good thing? And lists any disadvantages? I'm not just erecting obstacles: the trouble with email is that it is long and discursive, so it's really hard to find all the relevant messages, and even if you do each message only makes sense if you read the long sequence. > > I made a wiki page: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo > >> >> One question I have is this. Presumably >> f do stmts >> will be represented as >> HsApp (HsVar f) (HsDo ...stmts...) >> And should print without parens -- they are signalled by HsPar. So what about >> (HsApp (HsVar f) (HsDo ...stmts1..)) (HsDo ..stmts2..) >> How does that pretty-print. I suppose it should be >> f do stmts1 >> do stmts2 >> That is, it must use layout. But at the moment the pretty printer doesn't do that. > > It looks like the pretty printer always prints curly braces around do > statements (ppr_do_stmts in hsSyn/HsExpr.hs), so perhaps this is not > an issue? > > - Akio From vlad.z.4096 at gmail.com Mon Aug 22 05:35:53 2016 From: vlad.z.4096 at gmail.com (Index Int) Date: Mon, 22 Aug 2016 08:35:53 +0300 Subject: Moving ArgumentsDo forward In-Reply-To: References: Message-ID: Thank you for making this effort! I am glad someone has finally implemented ArgumentDo. I hope your patch gets merged. On Mon, Aug 22, 2016 at 8:11 AM, Akio Takano wrote: > I have put up an implementation: > https://github.com/takano-akio/ghc/commits/argumentdo > > Shall I submit the patch on the Phabricator, or should this go through > the new proposal submission process? > > Regards, > Takano Akio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Mon Aug 22 05:51:49 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 22 Aug 2016 11:21:49 +0530 Subject: Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: Thanks Mathieu. This works pretty well for gcc ( https://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html) but sadly it does not work for clang cpp as Brandon too pointed out earlier that clang does not have a traditional mode. -harendra On 22 August 2016 at 02:01, Boespflug, Mathieu wrote: > Hi Harendra, > > I ran into this very problem recently. Turns out -traditional knows string > concatenation too. I seem to remember learning this by browsing the GHC > source code, but now I can't find any occurrence of this pattern. But > here's an example of how to do string concatenation with CPP in > -traditional mode: https://github.com/tweag/sparkle/blob/ > a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/ > Foreign/JNI.hs#L274. > > HTH, > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > On 20 August 2016 at 20:33, Brandon Allbery wrote: > >> On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar > > wrote: >> >>> But "-optP" seems to only append to the flags that GHC already passes >>> and gcc has no "-no-traditional" option to undo the effect of the >>> "-traditional" that GHC has already passed. I think "-optP" should override >>> the flags passed by ghc rather than appending to them. Is there a reason >>> not to do that? >>> >>> Is there any other better way to achieve this? What is the standard way >>> of doing this if any? >>> >> >> Removing -traditional will break much Haskell source. Go look at the >> history of clang with ghc (clang doesn't do -traditional) to see what >> happens. (tl;dr: without -traditional, cpp knows too much about what >> constitutes valid C, and mangles and/or throws errors on valid Haskell that >> doesn't lex the way C does.) >> >> You might want to look at cpphs as an alternative preprocessor. There are >> some ancient K&R-era hacks that could be used if absolutely necessary, but >> cpphs should be a much simpler and cleaner solution. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkn.akio at gmail.com Mon Aug 22 05:55:42 2016 From: tkn.akio at gmail.com (Akio Takano) Date: Mon, 22 Aug 2016 05:55:42 +0000 Subject: Moving ArgumentsDo forward In-Reply-To: References: Message-ID: Thank you, but let me clarify that a significant portion of my patch was simply copied from Andrew Gibiansky's differential revision: https://phabricator.haskell.org/D1219 - Akio On 22 August 2016 at 05:35, Index Int wrote: > Thank you for making this effort! I am glad someone has finally implemented > ArgumentDo. I hope your patch gets merged. From simonpj at microsoft.com Mon Aug 22 09:13:49 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Aug 2016 09:13:49 +0000 Subject: SSH failing on Windows Message-ID: I'm continuing the saga of setting up my lovely Surface Book. Succeeding, just, but see below. Now my problem is that 'git push' doesn't work. My 'pushurl' is pushurl = ssh://git at git.haskell.org/ghc.git which is correct I think. I have a .ssh directory set up, with a copy of all the files that used to work. But 'git push' says /c/code/HEAD$ git push Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. So presumably it's a ssh problem. Turned out (via ssh -v) that I was getting debug1: Skipping ssh-dss key /c/users/simonpj/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes I solved this by adding to .ssh/config the line PubkeyAcceptedKeyTypes +ssh-dss But I guess this is bad practice. How would I (a) generate RSA keys (b) push them to git.haskell.org (or wherever they need to go) Is there a wiki page describing this? The (b) part at least is GHC specific, as is the strange pushurl. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Mon Aug 22 10:05:45 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 22 Aug 2016 20:05:45 +1000 Subject: SSH failing on Windows In-Reply-To: References: Message-ID: <20160822200545.d09ce711de9af1153bf7b28a@mega-nerd.com> Simon Peyton Jones via ghc-devs wrote: > Now my problem is that 'git push' doesn't work. My 'pushurl' is > pushurl = ssh://git at git.haskell.org/ghc.git > which is correct I think. Try pushurl = git at git.haskell.org/ghc.git I think the "ssh://" was for older versions of git. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mle+hs at mega-nerd.com Mon Aug 22 10:15:53 2016 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 22 Aug 2016 20:15:53 +1000 Subject: SSH failing on Windows In-Reply-To: References: Message-ID: <20160822201553.9cd93d90f155ce5bbecf6137@mega-nerd.com> Simon Peyton Jones via ghc-devs wrote: > > But 'git push' says > > /c/code/HEAD$ git push > > Permission denied (publickey). > > fatal: Could not read from remote repository. And then I read the error message. That message suggests that the SSH key is not known by the remote repository. Did you copy your SSH keys from your old machine to your new machine? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From carter.schonwald at gmail.com Mon Aug 22 12:05:51 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 22 Aug 2016 08:05:51 -0400 Subject: Request for feedback: deriving strategies syntax In-Reply-To: References: <4b876d2c-2b0c-7490-673f-0085646e0a86@gmail.com> Message-ID: Artisanal often means the same thing as bespoke in American English, though some times with an ironic / mocking subtext. At the same time, artisanal is often used with words like organic or natural. Which are often used in opposition to terms like synthetic or synthesized. In this context, it's even worse :) It is perfectly understandable for me to say "" I am using the built in ghc deriving machinery to synthesize the code for the natural functor definition of this data type "" I suppose it's bespoke in the sense that it's manufactured at most once, it's organic / natural in that there's usually only one accepted definition of the instance that is expected , and synthesized in that it's being manufactured by code rather than humans (yet not synthetic in that ghc comes with those particular derivation tactics, in contrast to user/library supplied codes) On Friday, August 19, 2016, Bardur Arantsson wrote: > (Sorry if anybody receives this twice, I think I flubbed my 'send'.) > > On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote: > > Yet my vote is with "bespoke". Short, informative, recognizable, and a > > nice balance of quirky and reasonable, just like so much else here. > > > > ... oh, and might I submit the opinion that quirky is not a quality that > to be desired of a programming language, even if it's only a keyword? > > (Anyway, I think I'll stop here. This is too much opinion for any > further discussion to be useful.) > > Regards, > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macek.0 at gmail.com Mon Aug 22 14:11:37 2016 From: david.macek.0 at gmail.com (David Macek) Date: Mon, 22 Aug 2016 16:11:37 +0200 Subject: SSH failing on Windows In-Reply-To: <20160822201553.9cd93d90f155ce5bbecf6137@mega-nerd.com> References: <20160822201553.9cd93d90f155ce5bbecf6137@mega-nerd.com> Message-ID: On 22. 8. 2016 12:15, Erik de Castro Lopo wrote: > And then I read the error message. That message suggests that the SSH key > is not known by the remote repository. Did you copy your SSH keys from > your old machine to your new machine? That was maybe also covered, see the quote below. > Simon Peyton Jones via ghc-devs wrote: >> I have a .ssh directory set up, with a copy of all the files that used to work. -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3834 bytes Desc: S/MIME Cryptographic Signature URL: From harendra.kumar at gmail.com Mon Aug 22 14:17:14 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 22 Aug 2016 19:47:14 +0530 Subject: Style or bug in user manual? Message-ID: I was working to fix some documentation and noticed that the user manual lists options like this: -package⟨pkg⟩ Notice that there is no space between the argument and the option. Should this be fixed? All options on this page seem to be similarly formatted which makes me wonder whether its by design? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Aug 22 15:59:11 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Aug 2016 15:59:11 +0000 Subject: SSH failing on Windows In-Reply-To: <20160822201553.9cd93d90f155ce5bbecf6137@mega-nerd.com> References: <20160822201553.9cd93d90f155ce5bbecf6137@mega-nerd.com> Message-ID: Thanks. Yes, I did copy the ssh keys over. As my email said, I think the underlying problem is that I should be using RSA keys not DSA keys. So I have to - generate a RSA key; I can manage that but I'm anxious about overwriting my existing DSA key - push the new RSA key to git.haskell.org, or ghc.haskell.org, or something I'm very unsure how to do that, since I think those machines don’t accept ssh connections Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Erik | de Castro Lopo | Sent: 22 August 2016 11:16 | To: ghc-devs at haskell.org | Subject: Re: SSH failing on Windows | | Simon Peyton Jones via ghc-devs wrote: | | > | > But 'git push' says | > | > /c/code/HEAD$ git push | > | > Permission denied (publickey). | > | > fatal: Could not read from remote repository. | | And then I read the error message. That message suggests that the SSH | key is not known by the remote repository. Did you copy your SSH keys | from your old machine to your new machine? | | Erik | -- | ---------------------------------------------------------------------- | Erik de Castro Lopo | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.me | ga- | nerd.com%2f&data=01%7c01%7csimonpj%40microsoft.com%7c93c60ec85fc048c5a | 7af08d3ca754fac%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dv4op8B%2 | bTYfQFBJtMn%2bwKXX0vQBemaPCyp135lspxbQ%3d | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40microsoft.com%7c93c60ec85fc048c5a7af08d3 | ca754fac%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Za%2fEdMqShmQ%2b | 0ax9PnhMUfHL77VzNZeXUiuBN34yIoA%3d From ben at smart-cactus.org Mon Aug 22 15:59:40 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 22 Aug 2016 11:59:40 -0400 Subject: Style or bug in user manual? In-Reply-To: References: Message-ID: <87shtwdcb7.fsf@smart-cactus.org> Harendra Kumar writes: > I was working to fix some documentation and noticed that the user manual > lists options like this: > > -package⟨pkg⟩ > > Notice that there is no space between the argument and the option. Should > this be fixed? All options on this page seem to be similarly formatted > which makes me wonder whether its by design? > Looking at docs/users_guide/packages.rst it appears there are indeed spaces in the source, which suggests that this is a bug in the parser in docs/users_guide/conf.py. Perhaps you could open a ticket (and of course feel free to take a stab at a solution)? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From harendra.kumar at gmail.com Mon Aug 22 18:56:26 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 23 Aug 2016 00:26:26 +0530 Subject: Style or bug in user manual? In-Reply-To: <87shtwdcb7.fsf@smart-cactus.org> References: <87shtwdcb7.fsf@smart-cactus.org> Message-ID: Thanks! I fixed it. On 22 August 2016 at 21:29, Ben Gamari wrote: > Harendra Kumar writes: > > > I was working to fix some documentation and noticed that the user manual > > lists options like this: > > > > -package⟨pkg⟩ > > > > Notice that there is no space between the argument and the option. Should > > this be fixed? All options on this page seem to be similarly formatted > > which makes me wonder whether its by design? > > > Looking at docs/users_guide/packages.rst it appears there are indeed > spaces in the source, which suggests that this is a bug in the parser in > docs/users_guide/conf.py. Perhaps you could open a ticket (and of course > feel free to take a stab at a solution)? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Tue Aug 23 15:43:23 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 23 Aug 2016 21:13:23 +0530 Subject: Errors when building users guide Message-ID: I see errors like this when using 'make html' in the topdir of the ghc repo: ---- /vol/hosts/cueball/workspace/github/ghc/docs/users_guide/flags.rst:15: SEVERE: Problems with "include" directive path: InputError: [Errno 2] No such file or directory: 'docs/users_guide/flags-verbosity.gen.rst'. ---- What am I doing wrong or not doing? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Aug 23 16:07:48 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 23 Aug 2016 12:07:48 -0400 Subject: Errors when building users guide In-Reply-To: References: Message-ID: <87y43ncvu3.fsf@smart-cactus.org> Harendra Kumar writes: > I see errors like this when using 'make html' in the topdir of the ghc repo: > Hmm, it looks like there is a missing dependency in the build system. The users guide depends upon a number of ReST source files generated by utils/mkUserGuidePart. I'd guess that you haven't built these. I'll look in to why this is but in the meantime the workaround is just to `make all` before attempting to `make html`. Sorry for the inconvenience! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From harendra.kumar at gmail.com Tue Aug 23 17:01:47 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 23 Aug 2016 22:31:47 +0530 Subject: Errors when building users guide In-Reply-To: <87y43ncvu3.fsf@smart-cactus.org> References: <87y43ncvu3.fsf@smart-cactus.org> Message-ID: Well, I tried 'make' and 'make all' (I suppose they are both same) but that did not make any difference. -harendra On 23 August 2016 at 21:37, Ben Gamari wrote: > Harendra Kumar writes: > > > I see errors like this when using 'make html' in the topdir of the ghc > repo: > > > Hmm, it looks like there is a missing dependency in the build system. > The users guide depends upon a number of ReST source files generated by > utils/mkUserGuidePart. I'd guess that you haven't built these. I'll look > in to why this is but in the meantime the workaround is just to `make > all` before attempting to `make html`. Sorry for the inconvenience! > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Tue Aug 23 18:31:16 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 24 Aug 2016 00:01:16 +0530 Subject: Errors when building users guide In-Reply-To: References: <87y43ncvu3.fsf@smart-cactus.org> Message-ID: I got to the bottom of the problem after some debugging. The short summary is - I was using "devel2" flavor which disables doc targets. The problem was it only disables them partially not fully. So even though I was able to invoke the targets I got these errors and the guide is mostly built except for the flags refs. The long story: devel2.mk sets: BUILD_SPHINX_HTML = NO But we 'include rules/sphinx.mk' in ghc.mk unconditionally. Now, since BUILD_SPHINX_HTML is not set we filter out mkUserGuidePart from build targets: BUILD_DIRS := $(filter-out utils/mkUserGuidePart,$(BUILD_DIRS)) This results in an inconsistent state of the doc targets being available but not the mkUserGuidePart rules. So even though I was able build the docs partially I was getting these errors. -harendra On 23 August 2016 at 22:31, Harendra Kumar wrote: > > Well, I tried 'make' and 'make all' (I suppose they are both same) but that did not make any difference. > > -harendra > > On 23 August 2016 at 21:37, Ben Gamari wrote: >> >> Harendra Kumar writes: >> >> > I see errors like this when using 'make html' in the topdir of the ghc repo: >> > >> Hmm, it looks like there is a missing dependency in the build system. >> The users guide depends upon a number of ReST source files generated by >> utils/mkUserGuidePart. I'd guess that you haven't built these. I'll look >> in to why this is but in the meantime the workaround is just to `make >> all` before attempting to `make html`. Sorry for the inconvenience! >> >> Cheers, >> >> - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue Aug 23 19:09:07 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 23 Aug 2016 15:09:07 -0400 Subject: Errors when building users guide In-Reply-To: References: <87y43ncvu3.fsf@smart-cactus.org> Message-ID: <87lgzncnfw.fsf@smart-cactus.org> Harendra Kumar writes: > I got to the bottom of the problem after some debugging. The short summary > is - I was using "devel2" flavor which disables doc targets. The problem > was it only disables them partially not fully. So even though I was able to > invoke the targets I got these errors and the guide is mostly built except > for the flags refs. > Good sleuthing! I suppose the Sphinx html targets should simply fail with an error when BUILD_SPHINX_HTML is not set. The right place to fix this is likely rules/sphinx.mk if you are interested in fixing this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From harendra.kumar at gmail.com Tue Aug 23 19:27:08 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 24 Aug 2016 00:57:08 +0530 Subject: Errors when building users guide In-Reply-To: <87lgzncnfw.fsf@smart-cactus.org> References: <87y43ncvu3.fsf@smart-cactus.org> <87lgzncnfw.fsf@smart-cactus.org> Message-ID: I already fixed it - https://phabricator.haskell.org/D2470 . On 24 August 2016 at 00:39, Ben Gamari wrote: > Harendra Kumar writes: > > > I got to the bottom of the problem after some debugging. The short > summary > > is - I was using "devel2" flavor which disables doc targets. The problem > > was it only disables them partially not fully. So even though I was able > to > > invoke the targets I got these errors and the guide is mostly built > except > > for the flags refs. > > > Good sleuthing! > > I suppose the Sphinx html targets should simply fail with an error when > BUILD_SPHINX_HTML is not set. The right place to fix this is likely > rules/sphinx.mk if you are interested in fixing this. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Aug 24 22:11:16 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 24 Aug 2016 18:11:16 -0400 Subject: Rewrapping with simple bidirectional pattern synonyms Message-ID: I'm trying to write a bidirectional pattern synonym which is morally simple, but as far as I can tell there's no way to write it as a simple bidirectional pattern synonym. What I want to say is pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) (where TSnocList and Dual are both newtype constructors) But I don't see a way to do it without being explicitly bidirectional: pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y tsViewR (TSnocList CL.TNil) = EmptyR tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x Would it be possible to make this simple thing simple? From ezyang at mit.edu Wed Aug 24 22:13:19 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 24 Aug 2016 15:13:19 -0700 Subject: Rewrapping with simple bidirectional pattern synonyms In-Reply-To: References: Message-ID: <1472076788-sup-2277@sabre> I filed a ticket for precisely this: https://ghc.haskell.org/trac/ghc/ticket/12203 Edward Excerpts from David Feuer's message of 2016-08-24 18:11:16 -0400: > I'm trying to write a bidirectional pattern synonym which is morally > simple, but as far as I can tell there's no way to write it as a > simple bidirectional pattern synonym. > > What I want to say is > > pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) > > (where TSnocList and Dual are both newtype constructors) > > But I don't see a way to do it without being explicitly bidirectional: > > pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where > TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) > > tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y > tsViewR (TSnocList CL.TNil) = EmptyR > tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x > > Would it be possible to make this simple thing simple? From matthewtpickering at gmail.com Wed Aug 24 22:13:29 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 24 Aug 2016 23:13:29 +0100 Subject: Rewrapping with simple bidirectional pattern synonyms In-Reply-To: References: Message-ID: The relevant ticket is - https://ghc.haskell.org/trac/ghc/ticket/12203 On Wed, Aug 24, 2016 at 11:11 PM, David Feuer wrote: > I'm trying to write a bidirectional pattern synonym which is morally > simple, but as far as I can tell there's no way to write it as a > simple bidirectional pattern synonym. > > What I want to say is > > pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) > > (where TSnocList and Dual are both newtype constructors) > > But I don't see a way to do it without being explicitly bidirectional: > > pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where > TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) > > tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y > tsViewR (TSnocList CL.TNil) = EmptyR > tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x > > Would it be possible to make this simple thing simple? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From david.feuer at gmail.com Wed Aug 24 22:52:12 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 24 Aug 2016 18:52:12 -0400 Subject: Rewrapping with simple bidirectional pattern synonyms In-Reply-To: <1472076788-sup-2277@sabre> References: <1472076788-sup-2277@sabre> Message-ID: I'm glad to see I'm not the only one who wants this! On Wed, Aug 24, 2016 at 6:13 PM, Edward Z. Yang wrote: > I filed a ticket for precisely this: > > https://ghc.haskell.org/trac/ghc/ticket/12203 > > Edward > > Excerpts from David Feuer's message of 2016-08-24 18:11:16 -0400: >> I'm trying to write a bidirectional pattern synonym which is morally >> simple, but as far as I can tell there's no way to write it as a >> simple bidirectional pattern synonym. >> >> What I want to say is >> >> pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) >> >> (where TSnocList and Dual are both newtype constructors) >> >> But I don't see a way to do it without being explicitly bidirectional: >> >> pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where >> TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) >> >> tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y >> tsViewR (TSnocList CL.TNil) = EmptyR >> tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x >> >> Would it be possible to make this simple thing simple? From omeragacan at gmail.com Thu Aug 25 10:45:58 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 25 Aug 2016 10:45:58 +0000 Subject: Can we mark DataCon ptrs only in allocation sites and not generate entry code? Message-ID: As far as I can see in the native code compiler we mark DataCon pointers in two places: 1. In allocation sites (StgCmmCon.hs:240) 2. In DataCon entry code (StgCmm.hs:244) I was wondering why we can't get away with just doing (1). Can anyone give me an example where an allocation doesn't return a tagged pointer and we need to tag it in entry code? If every allocation returns a tagged pointer, then why do we need (2) ? Thanks From simonpj at microsoft.com Thu Aug 25 15:10:12 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Aug 2016 15:10:12 +0000 Subject: [GHC] #12067: warn-unused-imports does not detect coersions In-Reply-To: <062.20745061b00face5488af0ef93e681fd@haskell.org> References: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> <062.20745061b00face5488af0ef93e681fd@haskell.org> Message-ID: ben is this a merge onto the 8.0 branch? On the ticket it just looks like a duplicate merge, which is jolly odd. This didn't use to happen... S | -----Original Message----- | From: GHC [mailto:ghc-devs at haskell.org] | Sent: 25 August 2016 16:04 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #12067: warn-unused-imports does not detect | coersions | | #12067: warn-unused-imports does not detect coersions | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: crockeea | Owner: | Type: bug | Status: merge | Priority: normal | Milestone: 8.0.2 | Component: Compiler | Version: 7.10.3 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Incorrect | Test Case: | warning at compile-time | | typecheck/should_compile/T12067 | Blocked By: | Blocking: | Related Tickets: #10347 | Differential Rev(s): | Wiki Page: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by Ben Gamari ): | | In [changeset:"6c28f24aa8202f79db49b85b815011703d647fd9/ghc" | 6c28f24/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="6c28f24aa8202f79db49b85b815011703d647fd9" | Deal correctly with unused imports for 'coerce' | | We only do newtype unwrapping for Coercible constraints if the | newtype's data constructor is in scope. We were trying to record the | fact that the data constructor was thereby 'used', so that an import | statement would not be flagged as unnecsssary (by -Wunused-imports). | | But the code was simply wrong. It was wrong because it assumed that | only one level of unwrapping happened, whereas | tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers. | So we need to return a /list/ of data constructors that are used. | | This entailed a bit of refactoring, as usual. | | Fixes Trac #12067 | | (cherry picked from commit 23b80ac41cc945cea0fc6ff9ade6b4be8aa81b7f) | }}} | | -- | Ticket URL: | | GHC | | The Glasgow Haskell Compiler From simonpj at microsoft.com Thu Aug 25 15:41:59 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Aug 2016 15:41:59 +0000 Subject: Can we mark DataCon ptrs only in allocation sites and not generate entry code? In-Reply-To: References: Message-ID: StgCmmCon.hs:240 reads ; return (mkRhsInit dflags reg lf_info hp_plus_n) } what's that got to do with pointer tagging? But yes we need to do it in both places. Consider f x xs = let y = x:xs in g y We should tag y before passing it to g. That's the StgCmmCon case. But also we clearly must do so in the entry code for a data constructor Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 25 August 2016 11:46 | To: ghc-devs | Subject: Can we mark DataCon ptrs only in allocation sites and not | generate entry code? | | As far as I can see in the native code compiler we mark DataCon | pointers in two places: | | 1. In allocation sites (StgCmmCon.hs:240) | 2. In DataCon entry code (StgCmm.hs:244) | | I was wondering why we can't get away with just doing (1). Can anyone | give me | an example where an allocation doesn't return a tagged pointer and we | need to | tag it in entry code? If every allocation returns a tagged pointer, | then why do | we need (2) ? | | Thanks | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40microsoft.com%7cb1571fb2c4e24941998308d3 | ccd519bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ilDdLBFdfvzY1g6Z | iuHyY6W%2bOIq2Y69f5YTgmpqwRO8%3d From omeragacan at gmail.com Thu Aug 25 16:45:30 2016 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 25 Aug 2016 16:45:30 +0000 Subject: Can we mark DataCon ptrs only in allocation sites and not generate entry code? In-Reply-To: References: Message-ID: > StgCmmCon.hs:240 reads > ; return (mkRhsInit dflags reg lf_info hp_plus_n) } > > what's that got to do with pointer tagging? If I understand correctly, mkRhsInit returns a tagged pointer: mkRhsInit :: DynFlags -> LocalReg -> LambdaFormInfo -> CmmExpr -> CmmAGraph mkRhsInit dflags reg lf_info expr = mkAssign (CmmLocal reg) (addDynTag dflags expr (lfDynTag dflags lf_info)) > But also we clearly must do so in the entry code for a data constructor Why? It's not clear to me. If every pointer to a constructor is tagged then maybe we don't need to enter constructors at all. 2016-08-25 15:41 GMT+00:00 Simon Peyton Jones : > StgCmmCon.hs:240 reads > ; return (mkRhsInit dflags reg lf_info hp_plus_n) } > > what's that got to do with pointer tagging? > > > But yes we need to do it in both places. Consider > > f x xs = let y = x:xs > in g y > > We should tag y before passing it to g. That's the StgCmmCon case. > > > But also we clearly must do so in the entry code for a data constructor > > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ömer > | Sinan Agacan > | Sent: 25 August 2016 11:46 > | To: ghc-devs > | Subject: Can we mark DataCon ptrs only in allocation sites and not > | generate entry code? > | > | As far as I can see in the native code compiler we mark DataCon > | pointers in two places: > | > | 1. In allocation sites (StgCmmCon.hs:240) > | 2. In DataCon entry code (StgCmm.hs:244) > | > | I was wondering why we can't get away with just doing (1). Can anyone > | give me > | an example where an allocation doesn't return a tagged pointer and we > | need to > | tag it in entry code? If every allocation returns a tagged pointer, > | then why do > | we need (2) ? > | > | Thanks > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | devs&data=01%7c01%7csimonpj%40microsoft.com%7cb1571fb2c4e24941998308d3 > | ccd519bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ilDdLBFdfvzY1g6Z > | iuHyY6W%2bOIq2Y69f5YTgmpqwRO8%3d From ryan.gl.scott at gmail.com Thu Aug 25 19:49:16 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 25 Aug 2016 15:49:16 -0400 Subject: Request for feedback: deriving strategies syntax Message-ID: Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S. From howard_b_golden at yahoo.com Thu Aug 25 19:49:44 2016 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Thu, 25 Aug 2016 12:49:44 -0700 Subject: Is there a stable URL for the latest GHC library haddocks? Message-ID: <661389ed-e004-77c9-acbe-f2c1646bad84@yahoo.com> Hi, In https://wiki.haskell.org/Unboxed_type I noticed a broken link to the latest library Haddock for GHC-Exts: http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html This link doesn't work because the version of base is omitted, but that will change over time. It works (at the moment) as: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.9.0.0/GHC-Exts.html Is there some stable URL that can be used in the wiki or other documentation to reference GHC library haddocks? Howard From ryan.gl.scott at gmail.com Thu Aug 25 19:54:45 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 25 Aug 2016 15:54:45 -0400 Subject: Is there a stable URL for the latest GHC library haddocks? Message-ID: Hi Howard, I've never had much luck with the Haddocks hosted on haskell.org, for whatever reason. If you're willing to link to Hackage, how about hackage.haskell.org/package/base/docs/GHC-Exts.html ? That currently redirects to http://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Exts.html, and will presumably continue to link to the most current Haddocks for GHC.Exts in the future. Best, Ryan S. From simonpj at microsoft.com Thu Aug 25 21:52:14 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Aug 2016 21:52:14 +0000 Subject: Can we mark DataCon ptrs only in allocation sites and not generate entry code? In-Reply-To: References: Message-ID: * Not every pointer to a datacon is tagged. The pointer might point to a thunk originally (one of many such pointers; then the thunk is updated to a datacon, but the pointer doesn't know that. * The tagging at dynamic allocation sites is optional. In f x xs = let y = x:xs in g y we don't HAVE to tag y. We could pass it untagged to g, which would evaluate it. But since we know it is a cons, it's silly NOT to tag it, because then g can avoid the eval. * In contrast, setting the tag in the entry code for the constructor is NOT optional, because it's part of the return protocol for returning from a constructor. Simon -----Original Message----- From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] Sent: 25 August 2016 17:46 To: Simon Peyton Jones Cc: ghc-devs Subject: Re: Can we mark DataCon ptrs only in allocation sites and not generate entry code? > StgCmmCon.hs:240 reads > ; return (mkRhsInit dflags reg lf_info hp_plus_n) } > > what's that got to do with pointer tagging? If I understand correctly, mkRhsInit returns a tagged pointer: mkRhsInit :: DynFlags -> LocalReg -> LambdaFormInfo -> CmmExpr -> CmmAGraph mkRhsInit dflags reg lf_info expr = mkAssign (CmmLocal reg) (addDynTag dflags expr (lfDynTag dflags lf_info)) > But also we clearly must do so in the entry code for a data > constructor Why? It's not clear to me. If every pointer to a constructor is tagged then maybe we don't need to enter constructors at all. 2016-08-25 15:41 GMT+00:00 Simon Peyton Jones : > StgCmmCon.hs:240 reads > ; return (mkRhsInit dflags reg lf_info hp_plus_n) } > > what's that got to do with pointer tagging? > > > But yes we need to do it in both places. Consider > > f x xs = let y = x:xs > in g y > > We should tag y before passing it to g. That's the StgCmmCon case. > > > But also we clearly must do so in the entry code for a data > constructor > > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Ömer Sinan Agacan > | Sent: 25 August 2016 11:46 > | To: ghc-devs > | Subject: Can we mark DataCon ptrs only in allocation sites and not > | generate entry code? > | > | As far as I can see in the native code compiler we mark DataCon > | pointers in two places: > | > | 1. In allocation sites (StgCmmCon.hs:240) 2. In DataCon entry code > | (StgCmm.hs:244) > | > | I was wondering why we can't get away with just doing (1). Can > | anyone give me an example where an allocation doesn't return a > | tagged pointer and we need to tag it in entry code? If every > | allocation returns a tagged pointer, then why do we need (2) ? > | > | Thanks > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail > | .h > | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- > | > | devs&data=01%7c01%7csimonpj%40microsoft.com%7cb1571fb2c4e24941998308 > | d3 > | ccd519bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ilDdLBFdfvzY1g > | 6Z > | iuHyY6W%2bOIq2Y69f5YTgmpqwRO8%3d From ben at smart-cactus.org Thu Aug 25 22:09:03 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 25 Aug 2016 18:09:03 -0400 Subject: [GHC] #12067: warn-unused-imports does not detect coersions In-Reply-To: References: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> <062.20745061b00face5488af0ef93e681fd@haskell.org> Message-ID: <87a8g0qz5s.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > ben is this a merge onto the 8.0 branch? On the ticket it just looks > like a duplicate merge, which is jolly odd. This didn't use to > happen... > Indeed, I enabled commit notifications on the stable branches earlier today in hopes that it would reduce the book-keeping costs associated with their maintenance. While it has been a bit easier, I was hoping that there would be some indication of which branch the commit is on in the Trac message. Would you prefer that I again disable these notifications on the stable branches? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Thu Aug 25 22:18:29 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Aug 2016 22:18:29 +0000 Subject: [GHC] #12067: warn-unused-imports does not detect coersions In-Reply-To: <87a8g0qz5s.fsf@smart-cactus.org> References: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> <062.20745061b00face5488af0ef93e681fd@haskell.org> <87a8g0qz5s.fsf@smart-cactus.org> Message-ID: I was hoping that there would be some indication of which branch the commit is on in the Trac message. Would you prefer that I again disable these notifications on the stable branches? Unless there is a clear indication of which branch, it's just confusing so better disabled. In my view - others may want to chime in. Simon -----Original Message----- From: Ben Gamari [mailto:ben at smart-cactus.org] Sent: 25 August 2016 23:09 To: Simon Peyton Jones ; ghc-devs at haskell.org Subject: RE: [GHC] #12067: warn-unused-imports does not detect coersions Simon Peyton Jones via ghc-devs > writes: > ben is this a merge onto the 8.0 branch? On the ticket it just looks > like a duplicate merge, which is jolly odd. This didn't use to > happen... > Indeed, I enabled commit notifications on the stable branches earlier today in hopes that it would reduce the book-keeping costs associated with their maintenance. While it has been a bit easier, I was hoping that there would be some indication of which branch the commit is on in the Trac message. Would you prefer that I again disable these notifications on the stable branches? Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Aug 25 22:21:58 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Aug 2016 18:21:58 -0400 Subject: Trac commit notifications on stable branches Message-ID: <877fb4qyk9.fsf@smart-cactus.org> Hello everyone, For a long time we've had a Git hook which adds comments to Trac tickets mentioned in commits on the master branch. Today I enabled similar notifications for the commits on the stable branches (e.g. ghc-8.0) in an attempt at reducing the overhead of maintaining the stable branches. Please let me know if you find these additional notifications too noisy. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Thu Aug 25 22:30:55 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 25 Aug 2016 23:30:55 +0100 Subject: Trac commit notifications on stable branches In-Reply-To: <877fb4qyk9.fsf@smart-cactus.org> References: <877fb4qyk9.fsf@smart-cactus.org> Message-ID: I did notice today that I received a lot of emails as you were merging patches to the stable branch. If it makes things much easier for you then I don't mind the extra notifications but it would perhaps be better to suppress email notification somehow. Matt On Thu, Aug 25, 2016 at 11:21 PM, Ben Gamari wrote: > Hello everyone, > > For a long time we've had a Git hook which adds comments to Trac tickets > mentioned in commits on the master branch. Today I enabled similar > notifications for the commits on the stable branches (e.g. ghc-8.0) in > an attempt at reducing the overhead of maintaining the stable branches. > Please let me know if you find these additional notifications too noisy. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ben at well-typed.com Thu Aug 25 23:06:17 2016 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Aug 2016 19:06:17 -0400 Subject: Trac commit notifications on stable branches In-Reply-To: References: <877fb4qyk9.fsf@smart-cactus.org> Message-ID: <8737lsqwie.fsf@smart-cactus.org> Matthew Pickering writes: > I did notice today that I received a lot of emails as you were merging > patches to the stable branch. > Well, the email volume was no different from my usual merge practices since I typically leave comments of the sort that the Trac hook produces manually. The only difference is this time they were automatically produced. Unfortunately, the Trac notification messages don't mention which branch the commit is on unlike the messages I typically leave manually. I'm evaluating options for fixing this. If it seemed like there was a lot of messages today that is merely because I was doing a lot of cleanup on the ghc-8.0 branch today. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From matthewtpickering at gmail.com Fri Aug 26 08:18:46 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 26 Aug 2016 09:18:46 +0100 Subject: Trac commit notifications on stable branches In-Reply-To: <8737lsqwie.fsf@smart-cactus.org> References: <877fb4qyk9.fsf@smart-cactus.org> <8737lsqwie.fsf@smart-cactus.org> Message-ID: Ah right my bad. Seems like a good change to me then. Matt On Fri, Aug 26, 2016 at 12:06 AM, Ben Gamari wrote: > Matthew Pickering writes: > >> I did notice today that I received a lot of emails as you were merging >> patches to the stable branch. >> > Well, the email volume was no different from my usual merge practices > since I typically leave comments of the sort that the Trac hook produces > manually. The only difference is this time they were automatically > produced. Unfortunately, the Trac notification messages don't mention > which branch the commit is on unlike the messages I typically leave > manually. I'm evaluating options for fixing this. > > If it seemed like there was a lot of messages today that is merely > because I was doing a lot of cleanup on the ghc-8.0 branch today. > > Cheers, > > - Ben > From ben at well-typed.com Fri Aug 26 13:38:14 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 26 Aug 2016 09:38:14 -0400 Subject: Action Required: Status of Harbormaster for Differentials Message-ID: <871t1br6pl.fsf@smart-cactus.org> tl;dr. I am working on restoring Harbormaster support for Differentials. Towards this end, GHC's Phabricator instance will soon require that you add an SSH public key to your account in order to upload patches with `arc diff`. Hello everyone, As you are no doubt aware Harbormaster has not been building Differentials for a very long time now. I am currently looking at options for restoring this service but it appears that doing so will require a bit of action on the part of our contributors. Specically, you will need to add an SSH key to Phabricator. You can do so by navigating to the Phabricator Settings [1] page, selecting the "Personal Account Settings" option, and selecting "SSH Public Keys" from the list on the left. There you can click on the "SSH Key Actions" menu on the top-right corner and click on the "Upload Public Key" item. Here you can specify a key name and paste the key contents (e.g. the contents of $HOME/.ssh/id_rsa.pub). The reason for this new requirement is that `arc diff` will soon push submitted diffs to a "staging area", a Git repository managed by Phabricator containing a branch for each submitted Differential. This will allow more reliable Harbormaster builds and merges as we will no longer need to rely on Phabricator correctly applying Differential patches (which has historically been problematic, especially for Differentials where the base commit is unavailable). If there are no objections, I would like to enable the staging area for the rGHC repository in three days, on Monday, 29 August 2016. After this date `arc diff` will try to push submitted differentials to the staging area, which will require a public key. Note, however, that pushing to the staging area can always be disabled with `arc diff`'s `--skip-staging` flag (although we won't be able to run CI builds on Differentials submitted in this way). To be clear: I would have liked to provide an option that did not require key-based authentication, but sadly neither Phabricator nor Gitolite provide any such option. I apologize for the added friction that this new requirement imposes. If enough people feel strongly that this is too onerous then I'm happy to entertain alternative solutions. Cheers, - Ben [1] https://phabricator.haskell.org/settings/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Fri Aug 26 14:56:07 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 26 Aug 2016 10:56:07 -0400 Subject: Cross-compiling Template Haskell via -fexternal-interpreter and IPC In-Reply-To: References: <87furmit8n.fsf@smart-cactus.org> Message-ID: <87vaynpojc.fsf@smart-cactus.org> Alberto Valverde writes: > On Thu, Jul 7, 2016 at 9:30 AM, Simon Marlow wrote: > >> I agree, named pipes are probably a better plan, perhaps a better solution >> overall than the way we currently pass FD numbers on the command line. Do >> named pipes work work as expected through wine? We would have to be >> careful to clean them up again afterwards. >> > > I've implemented IPC with named pipes and it appeared to work through wine > but now I'm investigating an issue which causes GHC to "freeze" when > talking to the external interpreter when it is not running on a TTY (ie: in > a build process) Hi Alterto, What ever happened to this? Is there any way I can be of assistance? It would be great to get this merged. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Fri Aug 26 18:18:30 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 Aug 2016 18:18:30 +0000 Subject: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic In-Reply-To: <20160826172332.1752.39958.F59C4961@phabricator.haskell.org> References: <20160826172332.1752.39958.F59C4961@phabricator.haskell.org> Message-ID: Ben or others Something is wrong with the .stderr file for T12531 (typed holes), which I just fixed. Not easy for me to sort out at home..might someone look? Or mark it as expect fail and I'll deal with it on Monday Thanks Simon From: noreply at phabricator.haskell.org [mailto:noreply at phabricator.haskell.org] Sent: 26 August 2016 18:24 To: Simon Peyton Jones Subject: [Diffusion] [Build Failed] rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic Harbormaster failed to build B10796: rGHCae66f356fb0d: Allow typed holes to be levity-polymorphic! BRANCHES master USERS simonpj (Author) O7 (Auditor) O11 (Auditor) COMMIT https://phabricator.haskell.org/rGHCae66f356fb0d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Aug 26 14:56:26 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 26 Aug 2016 16:56:26 +0200 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <871t1br6pl.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> Message-ID: <1472223386.29307.1.camel@joachim-breitner.de> Hi, Am Freitag, den 26.08.2016, 09:38 -0400 schrieb Ben Gamari: > The reason for this new requirement is that `arc diff` will soon push > submitted diffs to a "staging area", a Git repository managed by > Phabricator containing a branch for each submitted Differential. this is great, because it means that we can run performance builds via perf.haskell.org on all DRs automatically! Will the staging repository be publicly available? And will it also contain the usual branches (master, ghc-8.0, wip/), so that I can simply take that as the upstream repo for gipeda’s sake? Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Fri Aug 26 21:39:33 2016 From: ben at well-typed.com (Ben Gamari) Date: Fri, 26 Aug 2016 17:39:33 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <1472223386.29307.1.camel@joachim-breitner.de> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> Message-ID: <87inunp5uy.fsf@smart-cactus.org> Joachim Breitner writes: > [ Unknown signature status ] > Hi, > > Am Freitag, den 26.08.2016, 09:38 -0400 schrieb Ben Gamari: >> The reason for this new requirement is that `arc diff` will soon push >> submitted diffs to a "staging area", a Git repository managed by >> Phabricator containing a branch for each submitted Differential. > > this is great, because it means that we can run performance builds via > perf.haskell.org on all DRs automatically! > > Will the staging repository be publicly available? > Indeed, it's available at [1]. There are no > And will it also contain the usual branches (master, ghc-8.0, wip/), so > that I can simply take that as the upstream repo for gipeda’s sake? > Not as things are currently configured and I'm not sure how easy it would be to reliably accomplish this. The only thing you'll find in that repository currently is tags (not branches as I stated earlier; sorry!) with names of the form phabricator/base/1234 and phabricator/diff/1234. These contain the base and head commits of revision 1234, respectively. Note that 1234 does not identify a differential; rather it is a revision of a differential (e.g. the number that you see in the "ID" column of the history table fn a differential in the web interface). Cheers, - Ben [1] https://phabricator.haskell.org/diffusion/GHCDIFF/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Sat Aug 27 16:07:35 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 27 Aug 2016 12:07:35 -0400 Subject: Trying to refactor DeriveAnyClass, stuck on typechecker-related code Message-ID: Simon, I'm currently working on a solution to #12144, which changes the way inferred contexts for DeriveAnyClass works, as per your suggestion here [1]. I've made some good progress in that instances derived using DeriveAnyClass now emit contexts that are gathered from the default signatures of the derived class itself. However, I've come to an impasse. This approach currently fails to work with most GHC Generics-style classes, for reasons that I'll explain below. Consider this example (abridged from here [2]): data StrictMaybe a = StrictNothing | StrictJust !a deriving (FullyStrict, Generic) class FullyStrict a where fullyStrict :: proxy a -> Bool default fullyStrict :: (GFullyStrict (Rep a)) => proxy a -> Bool fullyStrict _ = gfullyStrict (Proxy :: Proxy (Rep a p)) With the new approach, the derived FullyStrict instance for StrictMaybe a will emit the context (GFullyStrict (Rep (StrictMaybe a)), but then fail with the error: No instance for (GFullyStrict (Rep (StrictMaybe a)) I think I understand why this is happening: if you look at the definition of tcDeriving in TcDeriv [3], it calls simplifyInstanceContexts, which would normally reduce type families like Rep. But the problem is that the Rep (StrictMaybe a) instance is also being derived at the same time (via the derived Generic instance)! What's worse, the call to simplifyInstanceContexts happens before the code that adds Rep (StrictMaybe a) to the type family instance environment (tcExtendLocalFamInstEnv (bagToList famInsts)). So simplifyInstanceContexts is unable to reduce Rep (StrictMaybe a), and as a result the context fails to simplify, resulting in the above error. This leads me to think we need to be adding Rep (StrictMaybe a) to the instance environment before calling simplifyInstanceContexts. But with the way the code is structured currently, I don't see an easy way to do this. The problem is that the genInst function [4] generates all of the following at the same time in one large bundle: * The instance code itself (InstInfo RdrName) * The associated type family instances (BagDerivStuff) * Auxiliary top-level bindings (BagDerivStuff) And within tcDeriving, the call to genInst takes as input the output of simplifyInstanceContexts, making it impossible to get the type family instances before calling simplifyInstanceContexts. Here are my questions: is it possible to take type family instances out of BagDerivStuff and instead add them to the instance environment before simplifyInstanceContexts? Would there be any typechecking issues involved with having the associated family instances in the local environment before the actual class instances themselves? Ryan S. ----- [1] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html [2] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/testsuite/tests/generics/GFullyStrict.hs [3] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l364 [4] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l2269 From lonetiger at gmail.com Sat Aug 27 16:20:36 2016 From: lonetiger at gmail.com (Phyx) Date: Sat, 27 Aug 2016 16:20:36 +0000 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <87inunp5uy.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> Message-ID: Hi Ben, Out of curiosity which platforms will be getting harbormaster support? Is this only Linux x86_64? Any plans to expand this in the future to all Tier 1 platforms? Cheers, Tamar On Fri, Aug 26, 2016, 22:39 Ben Gamari wrote: > Joachim Breitner writes: > > > [ Unknown signature status ] > > Hi, > > > > Am Freitag, den 26.08.2016, 09:38 -0400 schrieb Ben Gamari: > >> The reason for this new requirement is that `arc diff` will soon push > >> submitted diffs to a "staging area", a Git repository managed by > >> Phabricator containing a branch for each submitted Differential. > > > > this is great, because it means that we can run performance builds via > > perf.haskell.org on all DRs automatically! > > > > Will the staging repository be publicly available? > > > Indeed, it's available at [1]. There are no > > > And will it also contain the usual branches (master, ghc-8.0, wip/), so > > that I can simply take that as the upstream repo for gipeda’s sake? > > > Not as things are currently configured and I'm not sure how easy it > would be to reliably accomplish this. > > The only thing you'll find in that repository currently is tags (not > branches as I stated earlier; sorry!) with names of the form > phabricator/base/1234 and phabricator/diff/1234. These contain the base > and head commits of revision 1234, respectively. Note that 1234 does not > identify a differential; rather it is a revision of a differential (e.g. > the number that you see in the "ID" column of the history table fn a > differential in the web interface). > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/diffusion/GHCDIFF/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sat Aug 27 22:37:48 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sat, 27 Aug 2016 23:37:48 +0100 Subject: Trying to refactor DeriveAnyClass, stuck on typechecker-related code In-Reply-To: References: Message-ID: Ryan and I chatted about this on IRC and he has a plan to fix this problem. On Sat, Aug 27, 2016 at 5:07 PM, Ryan Scott wrote: > Simon, > > I'm currently working on a solution to #12144, which changes the way > inferred contexts for DeriveAnyClass works, as per your suggestion > here [1]. I've made some good progress in that instances derived using > DeriveAnyClass now emit contexts that are gathered from the default > signatures of the derived class itself. > > However, I've come to an impasse. This approach currently fails to > work with most GHC Generics-style classes, for reasons that I'll > explain below. Consider this example (abridged from here [2]): > > data StrictMaybe a = StrictNothing | StrictJust !a > deriving (FullyStrict, Generic) > > class FullyStrict a where > fullyStrict :: proxy a -> Bool > default fullyStrict :: (GFullyStrict (Rep a)) => proxy a -> Bool > fullyStrict _ = gfullyStrict (Proxy :: Proxy (Rep a p)) > > With the new approach, the derived FullyStrict instance for > StrictMaybe a will emit the context (GFullyStrict (Rep (StrictMaybe > a)), but then fail with the error: > > No instance for (GFullyStrict (Rep (StrictMaybe a)) > > I think I understand why this is happening: if you look at the > definition of tcDeriving in TcDeriv [3], it calls > simplifyInstanceContexts, which would normally reduce type families > like Rep. But the problem is that the Rep (StrictMaybe a) instance is > also being derived at the same time (via the derived Generic > instance)! What's worse, the call to simplifyInstanceContexts happens > before the code that adds Rep (StrictMaybe a) to the type family > instance environment (tcExtendLocalFamInstEnv (bagToList famInsts)). > So simplifyInstanceContexts is unable to reduce Rep (StrictMaybe a), > and as a result the context fails to simplify, resulting in the above > error. > > This leads me to think we need to be adding Rep (StrictMaybe a) to the > instance environment before calling simplifyInstanceContexts. But with > the way the code is structured currently, I don't see an easy way to > do this. The problem is that the genInst function [4] generates all of > the following at the same time in one large bundle: > > * The instance code itself (InstInfo RdrName) > * The associated type family instances (BagDerivStuff) > * Auxiliary top-level bindings (BagDerivStuff) > > And within tcDeriving, the call to genInst takes as input the output > of simplifyInstanceContexts, making it impossible to get the type > family instances before calling simplifyInstanceContexts. > > Here are my questions: is it possible to take type family instances > out of BagDerivStuff and instead add them to the instance environment > before simplifyInstanceContexts? Would there be any typechecking > issues involved with having the associated family instances in the > local environment before the actual class instances themselves? > > Ryan S. > ----- > [1] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html > [2] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/testsuite/tests/generics/GFullyStrict.hs > [3] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l364 > [4] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l2269 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Sun Aug 28 01:02:37 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 27 Aug 2016 21:02:37 -0400 Subject: Trying to refactor DeriveAnyClass, stuck on typechecker-related code In-Reply-To: References: Message-ID: Indeed, I managed to fix the type family reduction problem by partially CPSing the genInst function, which allowed me to collect the Rep instance and add it to the environment before invoking simplifyInstanceContexts. But I've ran into another, probably more fundamental issue. Consider the following example (adapted from https://ghc.haskell.org/trac/ghc/ticket/12423): class Eq1 f where (==#) :: forall a. Eq a => f a -> f a -> Bool default (==#) :: forall x y. (Eq (f x), Eq (f y)) => f x -> f y -> Bool (==#) x y = x == x && y == y data Foo a = Foo (Maybe a) deriving (Eq, Eq1) With my changes, the above derived Eq1 Foo instance will fail with the following error: No instance for (Eq x) arising from the first field of ‘Foo’ (type ‘Maybe a’) (But a manually defined Eq1 Foo works.) This error message is bizarre, but it makes sense when you think about how the new DeriveAnyClass context inference algorithm works: * First, GHC collects the constraints from the default signatures (Eq (f x), Eq (f y)) * Then, it substitutes the class variable (f) with the instantiated type (Foo) to obtain (Eq (Foo x), Eq (Foo y)) * Then, it reduces (Eq (Foo x), Eq (Foo y)) by using the existing instance Eq a => Eq (Maybe a) to obtain (Eq x, Eq y) * Then, it tries to solve (Eq x) as a wanted constraint At that point, GHC stops, since the only given constraint is (Eq a) from the (non-default) type signature for (==#), but the type variable a is completely different from x (and y)! For better or worse, the forall'd type variables in the non-default type signature for (==#) have no relation to the ones in the default type signature (cf. Trac #12533). Somehow, I have to figure out how to make GHC use (Eq a) to discharge the (Eq x) and (Eq y) obligations, but I have no idea how to do that. Does anyone have ideas? Ryan S. On Sat, Aug 27, 2016 at 6:37 PM, Matthew Pickering wrote: > Ryan and I chatted about this on IRC and he has a plan to fix this problem. > > On Sat, Aug 27, 2016 at 5:07 PM, Ryan Scott wrote: >> Simon, >> >> I'm currently working on a solution to #12144, which changes the way >> inferred contexts for DeriveAnyClass works, as per your suggestion >> here [1]. I've made some good progress in that instances derived using >> DeriveAnyClass now emit contexts that are gathered from the default >> signatures of the derived class itself. >> >> However, I've come to an impasse. This approach currently fails to >> work with most GHC Generics-style classes, for reasons that I'll >> explain below. Consider this example (abridged from here [2]): >> >> data StrictMaybe a = StrictNothing | StrictJust !a >> deriving (FullyStrict, Generic) >> >> class FullyStrict a where >> fullyStrict :: proxy a -> Bool >> default fullyStrict :: (GFullyStrict (Rep a)) => proxy a -> Bool >> fullyStrict _ = gfullyStrict (Proxy :: Proxy (Rep a p)) >> >> With the new approach, the derived FullyStrict instance for >> StrictMaybe a will emit the context (GFullyStrict (Rep (StrictMaybe >> a)), but then fail with the error: >> >> No instance for (GFullyStrict (Rep (StrictMaybe a)) >> >> I think I understand why this is happening: if you look at the >> definition of tcDeriving in TcDeriv [3], it calls >> simplifyInstanceContexts, which would normally reduce type families >> like Rep. But the problem is that the Rep (StrictMaybe a) instance is >> also being derived at the same time (via the derived Generic >> instance)! What's worse, the call to simplifyInstanceContexts happens >> before the code that adds Rep (StrictMaybe a) to the type family >> instance environment (tcExtendLocalFamInstEnv (bagToList famInsts)). >> So simplifyInstanceContexts is unable to reduce Rep (StrictMaybe a), >> and as a result the context fails to simplify, resulting in the above >> error. >> >> This leads me to think we need to be adding Rep (StrictMaybe a) to the >> instance environment before calling simplifyInstanceContexts. But with >> the way the code is structured currently, I don't see an easy way to >> do this. The problem is that the genInst function [4] generates all of >> the following at the same time in one large bundle: >> >> * The instance code itself (InstInfo RdrName) >> * The associated type family instances (BagDerivStuff) >> * Auxiliary top-level bindings (BagDerivStuff) >> >> And within tcDeriving, the call to genInst takes as input the output >> of simplifyInstanceContexts, making it impossible to get the type >> family instances before calling simplifyInstanceContexts. >> >> Here are my questions: is it possible to take type family instances >> out of BagDerivStuff and instead add them to the instance environment >> before simplifyInstanceContexts? Would there be any typechecking >> issues involved with having the associated family instances in the >> local environment before the actual class instances themselves? >> >> Ryan S. >> ----- >> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html >> [2] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/testsuite/tests/generics/GFullyStrict.hs >> [3] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l364 >> [4] http://git.haskell.org/ghc.git/blob/0050aff22ba04baca732bf5124002417ab667f8a:/compiler/typecheck/TcDeriv.hs#l2269 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Sun Aug 28 12:29:51 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 28 Aug 2016 08:29:51 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <87inunp5uy.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> Message-ID: <1472387391.3206.4.camel@joachim-breitner.de> Hi, Am Freitag, den 26.08.2016, 17:39 -0400 schrieb Ben Gamari: > Indeed, it's available at [1]. it does not seem to be world-readable: $ git fetch phab fatal: unable to access 'http://phabricator.haskell.org/diffusion/GHCDIFF/GHC-Differentials.git/': The requested URL returned error: 500 > The only thing you'll find in that repository currently is tags (not > branches as I stated earlier; sorry!) with names of the form > phabricator/base/1234 and phabricator/diff/1234. These contain the base > and head commits of revision 1234, respectively. Note that 1234 does not > identify a differential; rather it is a revision of a differential (e.g. > the number that you see in the "ID" column of the history table fn a > > ifferential in the web interface). Ok, I think I will have to add custom code to take care of DRs in gipeda, but it is probably worth it. Can I assume that phabricator/base/1234 is always (or at least usually) a commit on master, or some other branch in the ghc repository? Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Mon Aug 29 13:04:04 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 29 Aug 2016 09:04:04 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> Message-ID: <874m63iv5n.fsf@smart-cactus.org> Phyx writes: > Hi Ben, > > Out of curiosity which platforms will be getting harbormaster support? Is > this only Linux x86_64? > > Any plans to expand this in the future to all Tier 1 platforms? > Indeed I would like to get to this point. At the moment I am focusing on Linux x86_64 and Darwin x86_64. I may try to bring up an ARM as well. The other platforms would be subject to machine availability. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at smart-cactus.org Mon Aug 29 14:03:35 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 29 Aug 2016 10:03:35 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <1472387391.3206.4.camel@joachim-breitner.de> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> <1472387391.3206.4.camel@joachim-breitner.de> Message-ID: <871t17iseg.fsf@smart-cactus.org> Joachim Breitner writes: > [ Unknown signature status ] > Hi, > > Am Freitag, den 26.08.2016, 17:39 -0400 schrieb Ben Gamari: >> Indeed, it's available at [1]. > > it does not seem to be world-readable: > > $ git fetch phab > fatal: unable to access 'http://phabricator.haskell.org/diffusion/GHCDIFF/GHC-Differentials.git/': The requested URL returned error: 500 > Actually it looks like this was a configuration issue which broke Phabricator's HTTP git hosting. I believe I have fixed this but now seem to be fighting our CDN which I'll need help from the infrastructure guys for. Regardless, you should be able to clone the repo via ssh. >> The only thing you'll find in that repository currently is tags (not >> branches as I stated earlier; sorry!) with names of the form >> phabricator/base/1234 and phabricator/diff/1234. These contain the base >> and head commits of revision 1234, respectively. Note that 1234 does not >> identify a differential; rather it is a revision of a differential (e.g. >> the number that you see in the "ID" column of the history table fn a >> > ifferential in the web interface). > > Ok, I think I will have to add custom code to take care of DRs in > gipeda, but it is probably worth it. > This code won't strictly speaking be in gipeda, right? Rather, it would merely be a bit more logic in the build script, no? > Can I assume that phabricator/base/1234 is always (or at least usually) > a commit on master, or some other branch in the ghc repository? > Often it will be. However, I have in the past often opened "chains" of Differentials where the HEAD of one is the base commit of the next. Naturally in this case the base commit will not be in master. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Aug 29 14:19:34 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Aug 2016 10:19:34 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <871t17iseg.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> <1472387391.3206.4.camel@joachim-breitner.de> <871t17iseg.fsf@smart-cactus.org> Message-ID: <1472480374.3239.24.camel@joachim-breitner.de> Hi, Am Montag, den 29.08.2016, 10:03 -0400 schrieb Ben Gamari: > > > it does not seem to be world-readable: > > > > $ git fetch phab > > fatal: unable to access 'http://phabricator.haskell.org/diffusion/G > > HCDIFF/GHC-Differentials.git/': The requested URL returned error: > > 500 > > > Actually it looks like this was a configuration issue which broke > Phabricator's HTTP git hosting. I believe I have fixed this but now > seem to be fighting our CDN which I'll need help from the > infrastructure > guys for. > > Regardless, you should be able to clone the repo via ssh. Permission denied (publickey,keyboard-interactive). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. (This is without using an ssh key added to Phab – after all, I need a build service to poll that, and don’t want to hand out keys to that.) I’ll wait for the CDN to get working. > > > The only thing you'll find in that repository currently is tags (not > > > branches as I stated earlier; sorry!) with names of the form > > > phabricator/base/1234 and phabricator/diff/1234. These contain the base > > > and head commits of revision 1234, respectively. Note that 1234 does not > > > identify a differential; rather it is a revision of a differential (e.g. > > > the number that you see in the "ID" column of the history table fn a > > > > > > > > ifferential in the web interface). > > > > Ok, I think I will have to add custom code to take care of DRs in > > gipeda, but it is probably worth it. > > > This code won't strictly speaking be in gipeda, right? Rather, it would > merely be a bit more logic in the build script, no? Both. The build script needs to know that there are two repositories to poll from Gipeda needs to produce a section, like the one for branches, for DRs, which  have slightly different semantics (in particular, they have an explicit base commit that comparisons should be made against, which is not the case for git branches). Hmm. Links to git diffs would also have to go to a different place. Annoying complexity there. Maybe a separate gipeda instance is simpler (but would get in the way of comparing commits on Phab with commits on the main repo, and duplicate building work). I’ll have to think more about how this can be done in a viable way. Greetings, Joachim -- -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Mon Aug 29 14:29:23 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 29 Aug 2016 10:29:23 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <1472480374.3239.24.camel@joachim-breitner.de> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> <1472387391.3206.4.camel@joachim-breitner.de> <871t17iseg.fsf@smart-cactus.org> <1472480374.3239.24.camel@joachim-breitner.de> Message-ID: <87y43fhcn0.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > Am Montag, den 29.08.2016, 10:03 -0400 schrieb Ben Gamari: >> >> Regardless, you should be able to clone the repo via ssh. > > Permission denied (publickey,keyboard-interactive). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > (This is without using an ssh key added to Phab – after all, I need a > build service to poll that, and don’t want to hand out keys to that.) > Ahh, sure. Right, it's expected that ssh requires a key. Indeed http is more fitting for your bot. > I’ll wait for the CDN to get working. > I'll let you know when things have been sorted. >> > Ok, I think I will have to add custom code to take care of DRs in >> > gipeda, but it is probably worth it. >> > >> This code won't strictly speaking be in gipeda, right? Rather, it would >> merely be a bit more logic in the build script, no? > > Both. > > The build script needs to know that there are two repositories to poll from > > Gipeda needs to produce a section, like the one for branches, for DRs, > which  have slightly different semantics (in particular, they have an > explicit base commit that comparisons should be made against, which is > not the case for git branches). > Ahhh, I see. A nice point. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Aug 29 15:17:07 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 29 Aug 2016 11:17:07 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <87y43fhcn0.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> <1472223386.29307.1.camel@joachim-breitner.de> <87inunp5uy.fsf@smart-cactus.org> <1472387391.3206.4.camel@joachim-breitner.de> <871t17iseg.fsf@smart-cactus.org> <1472480374.3239.24.camel@joachim-breitner.de> <87y43fhcn0.fsf@smart-cactus.org> Message-ID: <87twe3hafg.fsf@smart-cactus.org> Ben Gamari writes: > Joachim Breitner writes: > >> Hi, >> ... > Ahh, sure. Right, it's expected that ssh requires a key. Indeed http is > more fitting for your bot. > >> I’ll wait for the CDN to get working. >> > I'll let you know when things have been sorted. > Well this is unfortunate: it looks like GHC might be too big [1] for Phabricator's HTTP git hosting logic. Unfortunately it's hard to claim this with much confidence since the endpoint provides no error message beyond a 500 status code. I'm not really sure what to advise here; I'll try to raise a flag with the Phacility people but even if I could confirm that T4369 is the culprit, it's a bug that still unfixed after more than two years and I don't hold out much hope that there will be a fix in the near-term. They suggest that affected users instead use SSH. Sadly this would mean that you would need to provide a key to your bot. It is certainly not a very satisfying answer, but I'm afraid it is likely the best we'll be able to do for a while. Cheers, - Ben [1] https://secure.phabricator.com/T4369 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Aug 29 19:00:41 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 29 Aug 2016 15:00:41 -0400 Subject: Last call for merge requests for 8.0.2 Message-ID: <87oa4bh02u.fsf@smart-cactus.org> tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up! Hello everyone, Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2. If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket. Thanks! - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ben at well-typed.com Mon Aug 29 19:33:42 2016 From: ben at well-typed.com (Ben Gamari) Date: Mon, 29 Aug 2016 15:33:42 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <871t1br6pl.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> Message-ID: <87k2ezgyjt.fsf@smart-cactus.org> Ben Gamari writes: > tl;dr. I am working on restoring Harbormaster support for Differentials. > Towards this end, GHC's Phabricator instance will soon require > that you add an SSH public key to your account in order to upload > patches with `arc diff`. > For the record, I just flipped the switch on this and enabled building of Differentials with Harbormaster. So far things look good but please let me know if you encounter any problems. Thanks! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From facundo.dominguez at tweag.io Mon Aug 29 21:02:26 2016 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Mon, 29 Aug 2016 18:02:26 -0300 Subject: Last call for merge requests for 8.0.2 In-Reply-To: <87oa4bh02u.fsf@smart-cactus.org> References: <87oa4bh02u.fsf@smart-cactus.org> Message-ID: Hello Ben, Could we have these patches added? http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17fc http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb7758b These allow reify to reach local variables when used with addModFinalizer. Best, Facundo On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari wrote: > tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see > merged into 8.0.2 and isn't already present in the tree, please > speak up! > > > Hello everyone, > > Over the last week I have been working down the (rather long) merge > queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this > point I think have merged nearly everything which will likely make it in > to 8.0.2. > > If you have a patch which hasn't made it to the ghc-8.0 branch that you > would like to see merged, please raise your concern on the appropriate > Trac ticket. > > Thanks! > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From iavor.diatchki at gmail.com Mon Aug 29 22:13:09 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 29 Aug 2016 15:13:09 -0700 Subject: Last call for merge requests for 8.0.2 In-Reply-To: References: <87oa4bh02u.fsf@smart-cactus.org> Message-ID: Hello, I don't have a patch, but I think that #12433 is a really serious bug that deserves a timely fix, as compiling with `-dynamic` on Linux produces code that runs but produces incorrect results. Unfortunately, I don't have time to look into it, and the bug is not in a part of the compiler I have experience with. -Iavor On Mon, Aug 29, 2016 at 2:02 PM, Facundo Domínguez < facundo.dominguez at tweag.io> wrote: > Hello Ben, > > Could we have these patches added? > > http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bd > e6473f17fc > http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f29 > 82cbb7758b > > These allow reify to reach local variables when used with addModFinalizer. > > Best, > Facundo > > On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari wrote: > > tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see > > merged into 8.0.2 and isn't already present in the tree, please > > speak up! > > > > > > Hello everyone, > > > > Over the last week I have been working down the (rather long) merge > > queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this > > point I think have merged nearly everything which will likely make it in > > to 8.0.2. > > > > If you have a patch which hasn't made it to the ghc-8.0 branch that you > > would like to see merged, please raise your concern on the appropriate > > Trac ticket. > > > > Thanks! > > > > - Ben > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Aug 30 14:38:52 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 30 Aug 2016 10:38:52 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <871t1br6pl.fsf@smart-cactus.org> References: <871t1br6pl.fsf@smart-cactus.org> Message-ID: <4FC76F7E-9E1E-4461-B1AE-5656EABC2D3B@cs.brynmawr.edu> Hi Ben, Thanks for tackling this difficult issue -- I know you've been looking for a better solution. As I understand it, anyone will now need to add a public key to Phab in order to upload patches. This (as you admit) will increase the barriers to contributions. Are the instructions for how a new contributor should submit patches (without a public key and therefore without CI) posted very visibly somewhere? Thanks, Richard > On Aug 26, 2016, at 9:38 AM, Ben Gamari wrote: > > tl;dr. I am working on restoring Harbormaster support for Differentials. > Towards this end, GHC's Phabricator instance will soon require > that you add an SSH public key to your account in order to upload > patches with `arc diff`. > > > Hello everyone, > > As you are no doubt aware Harbormaster has not been building > Differentials for a very long time now. I am currently looking at > options for restoring this service but it appears that doing so will > require a bit of action on the part of our contributors. > > Specically, you will need to add an SSH key to Phabricator. You can do > so by navigating to the Phabricator Settings [1] page, selecting the > "Personal Account Settings" option, and selecting "SSH Public Keys" from > the list on the left. There you can click on the "SSH Key Actions" > menu on the top-right corner and click on the "Upload Public Key" > item. Here you can specify a key name and paste the key contents > (e.g. the contents of $HOME/.ssh/id_rsa.pub). > > The reason for this new requirement is that `arc diff` will soon push > submitted diffs to a "staging area", a Git repository managed by Phabricator > containing a branch for each submitted Differential. This will allow more > reliable Harbormaster builds and merges as we will no longer need to > rely on Phabricator correctly applying Differential patches (which has > historically been problematic, especially for Differentials where the > base commit is unavailable). > > If there are no objections, I would like to enable the staging area for > the rGHC repository in three days, on Monday, 29 August 2016. After > this date `arc diff` will try to push submitted differentials to the > staging area, which will require a public key. Note, however, that > pushing to the staging area can always be disabled with `arc diff`'s > `--skip-staging` flag (although we won't be able to run CI builds on > Differentials submitted in this way). > > To be clear: I would have liked to provide an option that did not > require key-based authentication, but sadly neither Phabricator nor > Gitolite provide any such option. I apologize for the added friction > that this new requirement imposes. If enough people feel strongly that > this is too onerous then I'm happy to entertain alternative solutions. > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/settings/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Tue Aug 30 15:59:09 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Aug 2016 11:59:09 -0400 Subject: Last call for merge requests for 8.0.2 In-Reply-To: References: <87oa4bh02u.fsf@smart-cactus.org> Message-ID: <87d1kqgsdu.fsf@smart-cactus.org> Facundo Domínguez writes: > Hello Ben, > > Could we have these patches added? > > http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17fc > http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb7758b > > These allow reify to reach local variables when used with addModFinalizer. > Hmm, I'm not sure; #11832 is strictly speaking a feature request which we try to avoid merging in minor releases to avoid introducing bugs. Given that 8.2.1 isn't that far away (hopefully early 2017), how terrible would it be if we punted this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From m at tweag.io Tue Aug 30 18:05:22 2016 From: m at tweag.io (Boespflug, Mathieu) Date: Tue, 30 Aug 2016 20:05:22 +0200 Subject: Last call for merge requests for 8.0.2 In-Reply-To: <87d1kqgsdu.fsf@smart-cactus.org> References: <87oa4bh02u.fsf@smart-cactus.org> <87d1kqgsdu.fsf@smart-cactus.org> Message-ID: Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like cos :: Double -> Double cos x = [c| cos($x) |] to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c: cos :: Double -> Double cos x = [c| double { cos($double:x) } |] >From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished. We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible. But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly). -- Mathieu Boespflug Founder at http://tweag.io. On 30 August 2016 at 17:59, Ben Gamari wrote: > Facundo Domínguez writes: > > > Hello Ben, > > > > Could we have these patches added? > > > > http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bd > e6473f17fc > > http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f29 > 82cbb7758b > > > > These allow reify to reach local variables when used with > addModFinalizer. > > > Hmm, I'm not sure; #11832 is strictly speaking a feature request which > we try to avoid merging in minor releases to avoid introducing bugs. > Given that 8.2.1 isn't that far away (hopefully early 2017), how > terrible would it be if we punted this? > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Aug 30 20:04:05 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Aug 2016 16:04:05 -0400 Subject: Action Required: Status of Harbormaster for Differentials In-Reply-To: <4FC76F7E-9E1E-4461-B1AE-5656EABC2D3B@cs.brynmawr.edu> References: <871t1br6pl.fsf@smart-cactus.org> <4FC76F7E-9E1E-4461-B1AE-5656EABC2D3B@cs.brynmawr.edu> Message-ID: <871t16gh1m.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi Ben, > > Thanks for tackling this difficult issue -- I know you've been looking > for a better solution. > > As I understand it, anyone will now need to add a public key to Phab > in order to upload patches. This (as you admit) will increase the > barriers to contributions. Are the instructions for how a new > contributor should submit patches (without a public key and therefore > without CI) posted very visibly somewhere? > I have some edits of the Phabricator page [1] in the Wiki on-going as we speak (although mpickering deserves credit for doing the original edits working in mentions of the SSH key requirement). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Tue Aug 30 21:12:00 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Aug 2016 21:12:00 +0000 Subject: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef) In-Reply-To: <20160829192842.E791C3A300@ghc.haskell.org> References: <20160829192842.E791C3A300@ghc.haskell.org> Message-ID: Ryan I just wanted to thank you for all the work you are doing on 'deriving' and generics. It's a very useful part of GHC, but it's sufficiently complicated that it's hard to dive in and make a quick fix. You are giving it sustained attention, and have become very familiar with the code, which is exactly what it needs. Thank you! It's extremely valuable work. I am conscious that I owe you a code review on D2280, but this week is bad and next week is worse. If I don't get to it, let's sit down at ICFP. I should not be standing in the way. Has anyone else given it a good review? Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of git at git.haskell.org Sent: 29 August 2016 20:29 To: ghc-commits at haskell.org Subject: [commit: ghc] master: Remove unused DerivInst constructor for DerivStuff (f4384ef) Repository : ssh://git at git.haskell.org/ghc On branch : master Link : https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell.org%2ftrac%2fghc%2fchangeset%2ff4384ef5b42bb64b55d6c930ed9850a021796f36%2fghc&data=01%7c01%7csimonpj%40microsoft.com%7cde5175bbe587432dbce208d3d042b188%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=l7WnAtIxsN0brRXa5FKnFrEvk0pyxm48BIqyOiiiIx4%3d >--------------------------------------------------------------- commit f4384ef5b42bb64b55d6c930ed9850a021796f36 Author: Ryan Scott Date: Mon Aug 29 15:26:53 2016 -0400 Remove unused DerivInst constructor for DerivStuff Summary: Back when derived `Generic` instances used to generate auxiliary datatypes, they would also generate instances for those datatypes. Nowadays, GHC generics uses a `DataKinds`-based encoding that requires neither auxiliary datatypes (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances for them (the `DerivInst` constructor of `DerivStuff`). It appears that `DerivTyCon` constructor was removed at some point, but `DerivInst` never was. No `DerivInst` values are ever constructed, so we can safely remove it. Test Plan: It builds Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2481 >--------------------------------------------------------------- f4384ef5b42bb64b55d6c930ed9850a021796f36 compiler/typecheck/TcDeriv.hs | 5 ++--- compiler/typecheck/TcGenDeriv.hs | 22 +++++++++------------- 2 files changed, 11 insertions(+), 16 deletions(-) diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 70eaf5c..e38cfdc 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -387,13 +387,12 @@ tcDeriving deriv_infos deriv_decls ; let (inst_infos, deriv_stuff, maybe_fvs) = unzip3 (insts1 ++ insts2) ; loc <- getSrcSpanM - ; let (binds, famInsts, extraInstances) = - genAuxBinds loc (unionManyBags deriv_stuff) + ; let (binds, famInsts) = genAuxBinds loc (unionManyBags + deriv_stuff) ; dflags <- getDynFlags ; (inst_info, rn_binds, rn_dus) <- - renameDeriv is_boot (inst_infos ++ (bagToList extraInstances)) binds + renameDeriv is_boot inst_infos binds ; unless (isEmptyBag inst_info) $ liftIO (dumpIfSet_dyn dflags Opt_D_dump_deriv "Derived instances" diff --git a/compiler/typecheck/TcGenDeriv.hs b/compiler/typecheck/TcGenDeriv.hs index 2eb8c07..dce0b16 100644 --- a/compiler/typecheck/TcGenDeriv.hs +++ b/compiler/typecheck/TcGenDeriv.hs @@ -70,7 +70,6 @@ import Lexeme import FastString import Pair import Bag -import TcEnv (InstInfo) import StaticFlags( opt_PprStyle_Debug ) import ListSetOps ( assocMaybe ) @@ -90,12 +89,11 @@ data AuxBindSpec data DerivStuff -- Please add this auxiliary stuff = DerivAuxBind AuxBindSpec - -- Generics + -- Generics and DeriveAnyClass | DerivFamInst FamInst -- New type family instances -- New top-level auxiliary bindings | DerivHsBind (LHsBind RdrName, LSig RdrName) -- Also used for SYB - | DerivInst (InstInfo RdrName) -- New, auxiliary instances {- ************************************************************************ @@ -2346,11 +2344,11 @@ genAuxBindSpec loc (DerivMaxTag tycon) max_tag = case (tyConDataCons tycon) of data_cons -> toInteger ((length data_cons) - fIRST_TAG) -type SeparateBagsDerivStuff = -- AuxBinds and SYB bindings - ( Bag (LHsBind RdrName, LSig RdrName) - -- Extra bindings (used by Generic only) - , Bag (FamInst) -- Extra family instances - , Bag (InstInfo RdrName)) -- Extra instances +type SeparateBagsDerivStuff = + -- AuxBinds and SYB bindings + ( Bag (LHsBind RdrName, LSig RdrName) + -- Extra family instances (used by Generic and DeriveAnyClass) + , Bag (FamInst) ) genAuxBinds :: SrcSpan -> BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds loc b = genAuxBinds' b2 where @@ -2363,16 +2361,14 @@ genAuxBinds loc b = genAuxBinds' b2 where genAuxBinds' :: BagDerivStuff -> SeparateBagsDerivStuff genAuxBinds' = foldrBag f ( mapBag (genAuxBindSpec loc) (rm_dups b1) - , emptyBag, emptyBag) + , emptyBag ) f :: DerivStuff -> SeparateBagsDerivStuff -> SeparateBagsDerivStuff f (DerivAuxBind _) = panic "genAuxBinds'" -- We have removed these before f (DerivHsBind b) = add1 b f (DerivFamInst t) = add2 t - f (DerivInst i) = add3 i - add1 x (a,b,c) = (x `consBag` a,b,c) - add2 x (a,b,c) = (a,x `consBag` b,c) - add3 x (a,b,c) = (a,b,x `consBag` c) + add1 x (a,b) = (x `consBag` a,b) + add2 x (a,b) = (a,x `consBag` b) mkParentType :: TyCon -> Type -- Turn the representation tycon of a family into _______________________________________________ ghc-commits mailing list ghc-commits at haskell.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-commits&data=01%7c01%7csimonpj%40microsoft.com%7cde5175bbe587432dbce208d3d042b188%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=2q1osuJMIA3dpKobhP45kpQUw%2bYdE263ytCtEtf9Hlc%3d From ben at well-typed.com Tue Aug 30 21:46:34 2016 From: ben at well-typed.com (Ben Gamari) Date: Tue, 30 Aug 2016 17:46:34 -0400 Subject: Last call for merge requests for 8.0.2 In-Reply-To: References: <87oa4bh02u.fsf@smart-cactus.org> <87d1kqgsdu.fsf@smart-cactus.org> Message-ID: <87vayiexqd.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > Depends how you look at it I guess. It's arguably a fix to addModFinalizer, > which never really worked for the use case it was intended since it was > first introduced. This function was added by the author of > language-c-inline, who wanted things like > > cos :: Double -> Double > cos x = [c| cos($x) |] > > to work by having a new C wrapper function for the quasiquote be generated > and written to disk at the end of the type checking phase. Doing it at the > end means all quasiquotes in the whole module can be dumped at once. > Problem is, the type environment was not available by then, so the user was > forced to provide an explicit type annotation to help with the code > generation, as is done in inline-c: > > cos :: Double -> Double > cos x = [c| double { cos($double:x) } |] > > From GHC 7.8, types for locally bound variables weren't even available at > the quasiquotation site, for reasons. But it's perfectly safe to make them > available by the time all type checking is finished. > > We could wait of course, but in the meantime this is completely holding up > the "inline" features of inline-java. Because for inline-java we decided > that the (redundant) type annotations such as the above were really too > verbose in the case of Java, and would require significant hacks to the > language-java parser, so we don't support them. That's why I for one am > keen to have addModFinalizer make into a release as soon as possible. > > But I completely understand your risk aversion for a point release. Here's > some data to help you evaluate the risk: the patch is specific to TH > finalizers registered using addModFinalizer, a function that is currently > used by only one package out there at the moment: expandth (based on github > code search - short of being able to code search all of Hackage directly). > Fair enough; this is compelling enough a reason to me. I've gone ahead and merged it. However, would either you or Facundo be able to write a release notes entry? Thanks, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Tue Aug 30 22:07:00 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Aug 2016 22:07:00 +0000 Subject: Last call for merge requests for 8.0.2 In-Reply-To: References: <87oa4bh02u.fsf@smart-cactus.org> <87d1kqgsdu.fsf@smart-cactus.org> Message-ID: If it merges ok, I’d be inclined to put this in. · We know it’ll help someone (Mathieu and colleages). · It (should) affect a new and as-yet little-used feature, so it’s unlikely to harm anyone. (Of course, ANY change can have unexpected consequences.) · And you could regard it as a kind of bug-fix. I think we could bend the rules here. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Boespflug, Mathieu Sent: 30 August 2016 19:05 To: Ben Gamari Cc: GHC developers Subject: Re: Last call for merge requests for 8.0.2 Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like cos :: Double -> Double cos x = [c| cos($x) |] to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c: cos :: Double -> Double cos x = [c| double { cos($double:x) } |] From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished. We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible. But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly). -- Mathieu Boespflug Founder at http://tweag.io. On 30 August 2016 at 17:59, Ben Gamari > wrote: Facundo Domínguez > writes: > Hello Ben, > > Could we have these patches added? > > http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17fc > http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb7758b > > These allow reify to reach local variables when used with addModFinalizer. > Hmm, I'm not sure; #11832 is strictly speaking a feature request which we try to avoid merging in minor releases to avoid introducing bugs. Given that 8.2.1 isn't that far away (hopefully early 2017), how terrible would it be if we punted this? Cheers, - Ben _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcook at rcook.org Wed Aug 31 04:41:19 2016 From: rcook at rcook.org (Richard Cook) Date: Tue, 30 Aug 2016 21:41:19 -0700 Subject: hsc2hs fix Message-ID: Ben et al, I'm responding to your last call for merge requests ( https://mail.haskell.org/pipermail/ghc-devs/2016-August/012693.html). I would really like to get this fix to hsc2hs in if it all possible: https://phabricator.haskell.org/D2478 Thanks, Richard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Aug 31 15:35:21 2016 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 31 Aug 2016 11:35:21 -0400 Subject: hsc2hs fix In-Reply-To: References: Message-ID: <87r395eyti.fsf@smart-cactus.org> Richard Cook writes: > Ben et al, > > I'm responding to your last call for merge requests ( > https://mail.haskell.org/pipermail/ghc-devs/2016-August/012693.html). I > would really like to get this fix to hsc2hs in if it all possible: > Sure, I can try to merge it today. I'm still working on merging a set of patches including yours into master. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From ezyang at mit.edu Wed Aug 31 21:19:19 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 31 Aug 2016 14:19:19 -0700 Subject: Phabricator diffs not viewable by non-logged in users Message-ID: <1472678320-sup-7483@sabre> For example, if I am not logged in (try an incognito/private browsing session), https://phabricator.haskell.org/D2501 reports an error. Is this intentional? Seems poor, and also the diff is labeled as Public in the UI. I found this quite surprising. Edward