From ekmett at gmail.com Sun Mar 1 04:39:43 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 28 Feb 2015 23:39:43 -0500 Subject: Library_submissions and Call for Maintainers Message-ID: We've had a lot of feedback over the last few months trying to get clarification on the role of the core libraries committee, and on the libraries@ process in general. In particular, Simon Peyton Jones asked us in his own rather inimitable manner to make sure that we sat down and started documenting things. After all, we've now been at this for almost a year and a half, and have started to figure out what is working and what isn't. In response to that feedback, we've recently taken the time to go through and update the Library_submissions page rather extensively to better describe and refine the libraries@ process and better define the role of the core libraries committee. Changes of note: * Up until now we've been using the rather ad hoc definition of "core libraries" as libraries that come with the Haskell Platform and which are subject to the libraries@ proposal process. We've recently taken it upon ourselves to clarify this further. To that end we've updated the Library_submissions page with a detailed summary of what libraries are considered "core" and why. * It was brought to our attention that figuring out even where to file a bug report or feature request for a given library was a tricky concern. To that end we've added information on how to find the appropriate issue tracker to the form. Communication: There are two forms of potential communication breakdowns that we'd like to address. We're still working on figuring out a more effective way to communicate what changes are happening in the background out to the community, lest we wind up with another situation like the Foldable/Traversable Proposal, where it caught an appreciable segment of the community unaware. We've started at least tracking issues that impact modules defined in the Haskell report in GHC trac with "report-impact", but we still have a lot more to do on this front. We have also been asked to help clarify what happens to a proposal once it leaves the libraries@ mailing list, assuming that the proposal is accepted by the maintainer. The issue was raised that it wasn't clear when an issue had been dropped on the floor, and who has responsibility to carry it forward at each stage along the way. To that end, we've posted some basic responsiveness guidelines to help. We're not looking for a way to hold someone's feet to the fire, but merely for a way to keep proposals from getting stuck in limbo as they transition out of the libraries mailing list and into the hands of the maintainers. Maintainership: In an effort to maintain a greater level of throughput on issues that come along, we're trying to increase the number of projects that have active maintainers. Some of these aren't necessarily core libraries, but they are libraries that have been handed to the core libraries committee for maintenance. A couple of weeks back we sought out an active maintainer for the directory package, as it had accumulated several months worth of backlogged tickets, most of which just needed a clear head to make an informed decision about how to proceed. Phil Ruffwind and Elliot Robinson stepped up to fill this gap, and have been making a rather exciting amount of headway in clearing out the issue backlog, while managing to give those issues the consideration they are due. Emboldened by this success, we have a few other packages with which we'd like to do the same: * random We've had some truly excellent work done over the last couple of years on how to deal with "splitting" a random number generator in a cryptographically sound manner. I spent some time cleaning up a few outstanding issues for this package personally over the summer, but have not had nearly enough time to devote to the issue of how to integrate the outcome of the recent research on splitting, while simultaneously caring about performance and soundness. * unix We've had a number of issues accrete over time, particularly issues that have to do with portability to lesser used platforms such as OpenBSD. We've also had a lot of cooks in the kitchen, so the documentation style for this library is all over the place. We could use a solid maintainer for this package who is deeply familiar with unix internals, and who, preferably would like to deal with bringing some order to these cross platform concerns. * Win32 None of us on the current core libraries committee are *particularly* well versed in current windows issues. We have a new "windows task force" as well. Would the task force -- or someone involved or who would like to be involved in it -- be willing to pick this up and carry the torch? * old-time, old-locale, haskell98 and haskell2010 The old-time and old-locale libraries are primarily maintained because their contents are mentioned in the Haskell Report, which is/was (mostly) implemented in the haskell98 and haskell2010 packages. Three months ago, we determined to stop shipping these as boot libraries with the GHC as a consequence of the Applicative-Monad Proposal. (Issue #9590 ) While Herbert Valerio Riedel recently started working on a "fully compliant" version of the Haskell 2010 report, there is a reasonably large design surface in that area, balancing between perfect compatibility and pragmatic compatibility with other libraries. These libraries could use a more active official maintainer. Thank you for your time. Please do not hesitate to contact me (or reply) with questions, concerns, or thoughts. -Edward Kmett -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.robinson at argiopetech.com Sun Mar 1 05:09:36 2015 From: elliot.robinson at argiopetech.com (Elliot Robinson) Date: Sun, 1 Mar 2015 00:09:36 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: <20150301050936.GA28629@suwako.argiopetech.com> I would be happy to assume maintainership of `unix` with the goal of bringing order to cross-platform chaos. I'll also continue backing up Phil as a secondary maintainer of `directory`. -- Elliot Robinson GPG Key: 9FEDE59A On 02/28/15, Edward Kmett wrote: > We've had a lot of feedback over the last few months trying to get > clarification on the role of the core libraries committee, and on the > libraries@ process in general. In particular, Simon Peyton Jones asked us > in his own rather inimitable manner to make sure that we sat down and > started documenting things. After all, we've now been at this for almost a > year and a half, and have started to figure out what is working and what > isn't. > > In response to that feedback, we've recently taken the time to go through > and update the Library_submissions > page rather extensively to > better describe and refine the libraries@ process and better define the > role of the core libraries committee. > > Changes of note: > > * Up until now we've been using the rather ad hoc definition of "core > libraries" as libraries that come with the Haskell Platform and which are > subject to the libraries@ proposal process. We've recently taken it upon > ourselves to clarify this further. To that end we've updated the > Library_submissions page > with a detailed summary of what libraries are considered "core" and why. > > * It was brought to our attention that figuring out even where to file a > bug report or feature request for a given library was a tricky concern. To > that end we've added information on how to find the appropriate issue > tracker to the form. > > Communication: > > There are two forms of potential communication breakdowns that we'd like to > address. > > We're still working on figuring out a more effective way to communicate > what changes are happening in the background out to the community, lest we > wind up with another situation like the Foldable/Traversable Proposal, > where it caught an appreciable segment of the community unaware. We've > started at least tracking issues that impact modules defined in the Haskell > report in GHC trac with "report-impact", but we still have a lot more to do > on this front. > > We have also been asked to help clarify what happens to a proposal once it > leaves the libraries@ mailing list, assuming that the proposal is accepted > by the maintainer. The issue was raised that it wasn't clear when an issue > had been dropped on the floor, and who has responsibility to carry it > forward at each stage along the way. To that end, we've posted some > basic responsiveness > guidelines to > help. We're not looking for a way to hold someone's feet to the fire, but > merely for a way to keep proposals from getting stuck in limbo as they > transition out of the libraries mailing list and into the hands of the > maintainers. > > Maintainership: > > In an effort to maintain a greater level of throughput on issues that come > along, we're trying to increase the number of projects that have active > maintainers. Some of these aren't necessarily core libraries, but they are > libraries that have been handed to the core libraries committee for > maintenance. > > A couple of weeks back we sought out an active maintainer for the directory > package, as it had accumulated several months worth of backlogged tickets, > most of which just needed a clear head to make an informed decision about > how to proceed. Phil Ruffwind and Elliot Robinson stepped up to fill this > gap, and have been making a rather exciting amount of headway in clearing > out the issue backlog, while managing to give those issues the > consideration they are due. > > Emboldened by this success, we have a few other packages with which we'd > like to do the same: > > * random > > We've had some truly excellent work done over the last couple of years on > how to deal with "splitting" a random number generator in a > cryptographically sound manner. I spent some time cleaning up a few > outstanding issues for this package personally over the summer, but have > not had nearly enough time to devote to the issue of how to integrate the > outcome of the recent research on splitting, while simultaneously caring > about performance and soundness. > > * unix > > We've had a number of issues accrete over time, particularly issues that > have to do with portability to lesser used platforms such as OpenBSD. We've > also had a lot of cooks in the kitchen, so the documentation style for this > library is all over the place. We could use a solid maintainer for this > package who is deeply familiar with unix internals, and who, preferably > would like to deal with bringing some order to these cross platform > concerns. > > * Win32 > > None of us on the current core libraries committee are *particularly* well > versed in current windows issues. We have a new "windows task force" as > well. Would the task force -- or someone involved or who would like to be > involved in it -- be willing to pick this up and carry the torch? > > * old-time, old-locale, haskell98 and haskell2010 > > The old-time and old-locale libraries are primarily maintained because > their contents are mentioned in the Haskell Report, which is/was (mostly) > implemented in the haskell98 and haskell2010 packages. Three months ago, we > determined to stop shipping these as boot libraries with the GHC as a > consequence of the Applicative-Monad Proposal. (Issue #9590 > ) While Herbert Valerio > Riedel recently started working on a "fully compliant" version of the > Haskell 2010 report, there is a reasonably large design surface in that > area, balancing between perfect compatibility and pragmatic compatibility > with other libraries. These libraries could use a more active official > maintainer. > > Thank you for your time. Please do not hesitate to contact me (or reply) > with questions, concerns, or thoughts. > > -Edward Kmett > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From gershomb at gmail.com Sun Mar 1 05:26:38 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 1 Mar 2015 00:26:38 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: On February 28, 2015 at 11:39:48 PM, Edward Kmett (ekmett at gmail.com) wrote: > * random > > We've had some truly excellent work done over the last couple of years on > how to deal with "splitting" a random number generator in a > cryptographically sound manner. I spent some time cleaning up a few > outstanding issues for this package personally over the summer, but have > not had nearly enough time to devote to the issue of how to integrate the > outcome of the recent research on splitting, while simultaneously caring > about performance and soundness. With regards to random, rather than making System.Random crypographically sound (which, as I understand it, could require changes to the API), there is a ?halfway house? approach ? implementation of the SplitMix algorithm of Steele, Lea and Flood [1]. This algorithm, now included in Java JDK8, claims that it is a "version of the purely functional API used in the Haskell library for over a decade, but SplitMix is faster and produces pseudorandom sequences of higher quality.? I am not volunteering to work on such a project, but it seems like it could not only be worthwhile, but quite a bit of fun for somebody with the right inclination. [1]?http://dl.acm.org/citation.cfm?id=2660195&CFID=630640078&CFTOKEN=34009864 Cheers, Gershom From thomas.dubuisson at gmail.com Sun Mar 1 05:30:11 2015 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat, 28 Feb 2015 21:30:11 -0800 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: On Sat, Feb 28, 2015 at 8:39 PM, Edward Kmett wrote: > * random > > We've had some truly excellent work done over the last couple of years on > how to deal with "splitting" a random number generator in a > cryptographically sound manner. I spent some time cleaning up a few > outstanding issues for this package personally over the summer, but have not > had nearly enough time to devote to the issue of how to integrate the > outcome of the recent research on splitting, while simultaneously caring > about performance and soundness. 'random' has been on bad-footing for a while in terms of API and functionality. I can re-produce my issues if desired, but a core question seems to be acceptability. Is tf-random not pleasing to enough people? Or the splitting is too slow? I don't currently know of any users who want high performing _and_ cryptographically sound generators, though that would be great to have. I am only currently aware of cryptographic PRNGs with slow (ish) split times and statistically decent PRNGs with good split times. I've had to fix two commercial projects now that had used StdGen so I'm willing to do significant work getting a PRNG with both properties if we can quantify the performance requirements. So far my best options appear to be tf-random or a 800-90 style CTR DRBG that's computes large buffers resulting in high memory use and decent _amortized_ performance (including split). -TomMD From thomas.dubuisson at gmail.com Sun Mar 1 05:32:15 2015 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sat, 28 Feb 2015 21:32:15 -0800 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: On Sat, Feb 28, 2015 at 9:30 PM, Thomas DuBuisson wrote: > I don't currently know > of any users who want high performing _and_ cryptographically sound > generators Sorry, I ment to say: I don't know of any users who need a high performance split operation in a cryptographically sound generator. Obviously the actual generation of random bits should be high performance no matter what. Thomas From ekmett at gmail.com Sun Mar 1 06:26:30 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 1 Mar 2015 01:26:30 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: I'm not wedded to either approach on splitting. I'm mostly concerned that we have someone who is at least giving these topics consideration. -Edward On Sun, Mar 1, 2015 at 12:26 AM, Gershom B wrote: > On February 28, 2015 at 11:39:48 PM, Edward Kmett (ekmett at gmail.com) > wrote: > > * random > > > > We've had some truly excellent work done over the last couple of years on > > how to deal with "splitting" a random number generator in a > > cryptographically sound manner. I spent some time cleaning up a few > > outstanding issues for this package personally over the summer, but have > > not had nearly enough time to devote to the issue of how to integrate the > > outcome of the recent research on splitting, while simultaneously caring > > about performance and soundness. > > With regards to random, rather than making System.Random crypographically > sound (which, as I understand it, could require changes to the API), there > is a ?halfway house? approach ? implementation of the SplitMix algorithm of > Steele, Lea and Flood [1]. This algorithm, now included in Java JDK8, > claims that it is a "version of the purely functional API used in the > Haskell library for over a decade, but SplitMix is faster and produces > pseudorandom sequences of higher quality.? > > I am not volunteering to work on such a project, but it seems like it > could not only be worthwhile, but quite a bit of fun for somebody with the > right inclination. > > [1] > http://dl.acm.org/citation.cfm?id=2660195&CFID=630640078&CFTOKEN=34009864 > > Cheers, > Gershom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 1 06:37:55 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 1 Mar 2015 01:37:55 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: i'd be interested in at least being a comaintainer of random. A lot of work i'm doing lately depends on having high quality + performant RNGs in haskell. (i do think its a sufficiently subtle domain that 2 heads are better than one for steering the course mind you) On Sun, Mar 1, 2015 at 1:26 AM, Edward Kmett wrote: > I'm not wedded to either approach on splitting. I'm mostly concerned that > we have someone who is at least giving these topics consideration. > > -Edward > > On Sun, Mar 1, 2015 at 12:26 AM, Gershom B wrote: > >> On February 28, 2015 at 11:39:48 PM, Edward Kmett (ekmett at gmail.com) >> wrote: >> > * random >> > >> > We've had some truly excellent work done over the last couple of years >> on >> > how to deal with "splitting" a random number generator in a >> > cryptographically sound manner. I spent some time cleaning up a few >> > outstanding issues for this package personally over the summer, but have >> > not had nearly enough time to devote to the issue of how to integrate >> the >> > outcome of the recent research on splitting, while simultaneously caring >> > about performance and soundness. >> >> With regards to random, rather than making System.Random crypographically >> sound (which, as I understand it, could require changes to the API), there >> is a ?halfway house? approach ? implementation of the SplitMix algorithm of >> Steele, Lea and Flood [1]. This algorithm, now included in Java JDK8, >> claims that it is a "version of the purely functional API used in the >> Haskell library for over a decade, but SplitMix is faster and produces >> pseudorandom sequences of higher quality.? >> >> I am not volunteering to work on such a project, but it seems like it >> could not only be worthwhile, but quite a bit of fun for somebody with the >> right inclination. >> >> [1] >> http://dl.acm.org/citation.cfm?id=2660195&CFID=630640078&CFTOKEN=34009864 >> >> Cheers, >> Gershom >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sun Mar 1 12:29:33 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Sun, 1 Mar 2015 12:29:33 +0000 (UTC) Subject: =?utf-8?b?TGlicmFyeV9zdWJtaXNzaW9ucw==?= and Call for Maintainers References: Message-ID: Edward Kmett gmail.com> writes: > Emboldened by this success, we have a few other packages with which > we'd like to do the same: * random? We've had some truly excellent > work done over the last couple of years on how to deal with > "splitting" a random number generator in a cryptographically sound > manner. I spent some time cleaning up a few outstanding issues for > this package personally over the summer, but have not had nearly > enough time to devote to the issue of how to integrate the outcome > of the recent research on splitting, while simultaneously caring > about performance and soundness. I'd like to throw my hat in the ring and become a co-maintainer also. I use random numbers a lot for various Monte Carlo simulations. From carter.schonwald at gmail.com Sun Mar 1 16:23:56 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 1 Mar 2015 11:23:56 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: I'd enjoy that I think! btw, ErikD pointed out an interesting family of RNGs yesterday http://www.pcg-random.org/ (though any new major version revisions of random should have a much more substantial test suite we need to run before doing a release, but thats a discussion for another time : ) ) On Sun, Mar 1, 2015 at 7:29 AM, Dominic Steinitz wrote: > Edward Kmett gmail.com> writes: > > > Emboldened by this success, we have a few other packages with which > > we'd like to do the same: * random We've had some truly excellent > > work done over the last couple of years on how to deal with > > "splitting" a random number generator in a cryptographically sound > > manner. I spent some time cleaning up a few outstanding issues for > > this package personally over the summer, but have not had nearly > > enough time to devote to the issue of how to integrate the outcome > > of the recent research on splitting, while simultaneously caring > > about performance and soundness. > > I'd like to throw my hat in the ring and become a co-maintainer > also. I use random numbers a lot for various Monte Carlo simulations. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Sun Mar 1 19:14:56 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 1 Mar 2015 11:14:56 -0800 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: <20150301111456.7fceae0fd739f85df0e478b4@mega-nerd.com> Carter Schonwald wrote: > I'd enjoy that I think! btw, ErikD pointed out an interesting family of > RNGs yesterday > http://www.pcg-random.org/ (though any new major version revisions of > random should have a much more substantial test suite we need to run before > doing a release, but thats a discussion for another time : ) ) There is already a haskell library implementing this: https://github.com/cchalmers/pcg-random Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From carter.schonwald at gmail.com Sun Mar 1 20:01:24 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 1 Mar 2015 15:01:24 -0500 Subject: Library_submissions and Call for Maintainers In-Reply-To: <20150301111456.7fceae0fd739f85df0e478b4@mega-nerd.com> References: <20150301111456.7fceae0fd739f85df0e478b4@mega-nerd.com> Message-ID: hey Erik, hrm, intersting! At least as starting point, interesting, though I already see some ways it could be made even purer+threadsafer+faster, thanks! On Sun, Mar 1, 2015 at 2:14 PM, Erik de Castro Lopo wrote: > Carter Schonwald wrote: > > > I'd enjoy that I think! btw, ErikD pointed out an interesting family of > > RNGs yesterday > > http://www.pcg-random.org/ (though any new major version revisions of > > random should have a much more substantial test suite we need to run > before > > doing a release, but thats a discussion for another time : ) ) > > There is already a haskell library implementing this: > > https://github.com/cchalmers/pcg-random > > Erik > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Mar 1 22:13:10 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 01 Mar 2015 23:13:10 +0100 Subject: Should foldl' be added to the post-"Plan FTP" Prelude References: <20150226.093145.1386058826244716294.kazu@iij.ad.jp> Message-ID: Why not? David Feuer wrote: > No, that is not a way now that we have FTP. > > On Wed, Feb 25, 2015 at 7:31 PM, Kazu Yamamoto wrote: >>> I would love to have foldl' as part of the Prelude. I use it quite >>> frequently and it seems like a beginner trap to have foldl but not >>> foldl' (which is almost always the better choice). I see that foldMap >>> has been added (in addition to all of Monoid and Traversable), why was >>> foldl' left out? >> >> That is one way but I think another way is to make foldl strict: >> >> http://www.well-typed.com/blog/90/ >> >> I'm tired of explaining the difference of foldl and foldl' to >> beginners. :-) >> >> --Kazu From winterkoninkje at gmail.com Sun Mar 1 22:40:01 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 1 Mar 2015 17:40:01 -0500 Subject: Proposal: Add (<$>) to Prelude as part of the AMP in GHC 7.10-RC3 In-Reply-To: References: Message-ID: On Tue, Feb 24, 2015 at 10:39 AM, Edward Kmett wrote: > We have a couple of weeks until the third release candidate for GHC 7.10 > goes out the door. > > Along the way with the last couple of release candidates folks have found > some problems with the way we implemented the AMP. [1][2] > > Most notably, we failed to include (<$>) in the Prelude, so the standard > idiom of > > foo <$> bar <*> baz <*> quux > > doesn't work out of the box! > > I'd like to include (<$>) in the Prelude in RC3. > > I'd also like to invite discussion about whether folks believe we should > include (<$) out of the box. Strong +1 for (<$>). I often use (<$>) for non-applicative functors whenever it helps reduce clutter. As far as the comment about encouraging people to use pure, the whole point of (<$>) being an alias for fmap is that (f <$> x) can be a significant optimization over (pure f <*> x). Ambivalent about (<$) -- Live well, ~wren From david.feuer at gmail.com Mon Mar 2 00:35:47 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 1 Mar 2015 19:35:47 -0500 Subject: Should foldl' be added to the post-"Plan FTP" Prelude In-Reply-To: References: <20150226.093145.1386058826244716294.kazu@iij.ad.jp> Message-ID: FTP sets up the expectation that foldl has a specific relationship to foldMap. I suppose you could go against that, and also break any code relying on the current foldl semantics, but I'd personally be very much opposed to that. On Mar 1, 2015 5:13 PM, "Ben Franksen" wrote: > Why not? > > David Feuer wrote: > > No, that is not a way now that we have FTP. > > > > On Wed, Feb 25, 2015 at 7:31 PM, Kazu Yamamoto wrote: > >>> I would love to have foldl' as part of the Prelude. I use it quite > >>> frequently and it seems like a beginner trap to have foldl but not > >>> foldl' (which is almost always the better choice). I see that foldMap > >>> has been added (in addition to all of Monoid and Traversable), why was > >>> foldl' left out? > >> > >> That is one way but I think another way is to make foldl strict: > >> > >> http://www.well-typed.com/blog/90/ > >> > >> I'm tired of explaining the difference of foldl and foldl' to > >> beginners. :-) > >> > >> --Kazu > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 2 09:07:29 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Mar 2015 09:07:29 +0000 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBB3FC@DB3PRD3001MB020.064d.mgd.msft.net> | the SplitMix algorithm of Steele, Lea and Flood [1]. | This algorithm, now included in Java JDK8, claims that it is a | "version of the purely functional API used in the Haskell library for | over a decade, but SplitMix is faster and produces pseudorandom | sequences of higher quality.? Moreover, SplitMix has a published paper to describe it, which is massively better (in a tricky area) than an un-documented pile of code. I knew that Guy was working on this but I didn't know it was now published. Excellent! I would love to see this happen Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of | Gershom B | Sent: 01 March 2015 05:27 | To: Edward Kmett; Haskell Libraries | Subject: Re: Library_submissions and Call for Maintainers | | On February 28, 2015 at 11:39:48 PM, Edward Kmett (ekmett at gmail.com) | wrote: | > * random | > | > We've had some truly excellent work done over the last couple of | years | > on how to deal with "splitting" a random number generator in a | > cryptographically sound manner. I spent some time cleaning up a few | > outstanding issues for this package personally over the summer, but | > have not had nearly enough time to devote to the issue of how to | > integrate the outcome of the recent research on splitting, while | > simultaneously caring about performance and soundness. | | With regards to random, rather than making System.Random | crypographically sound (which, as I understand it, could require | changes to the API), there is a ?halfway house? approach ? | implementation of the SplitMix algorithm of Steele, Lea and Flood [1]. | This algorithm, now included in Java JDK8, claims that it is a | "version of the purely functional API used in the Haskell library for | over a decade, but SplitMix is faster and produces pseudorandom | sequences of higher quality.? | | I am not volunteering to work on such a project, but it seems like it | could not only be worthwhile, but quite a bit of fun for somebody with | the right inclination. | | [1]?http://dl.acm.org/citation.cfm?id=2660195&CFID=630640078&CFTOKEN=3 | 4009864 | | Cheers, | Gershom | _______________________________________________ | Libraries mailing list | Libraries at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From alexander at plaimi.net Mon Mar 2 10:22:32 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 02 Mar 2015 11:22:32 +0100 Subject: Proposal to deprecate and then drop fromJust In-Reply-To: <20150223214222.0071ff0a14f312cebd70d683@mega-nerd.com> References: <20150223214222.0071ff0a14f312cebd70d683@mega-nerd.com> Message-ID: <54F439E8.5050303@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1 to deprecating and dropping fromJust. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlT0OeYACgkQRtClrXBQc7U1fQD+LnkIjEElxkdBeprT6GQ08w6Z +Chn0Xdw1PHbVfZ5LugA/1C5/v5IAVygK/Gpy3cApbCGIPI0ddKLDSdoL8IV6bxw =sKC1 -----END PGP SIGNATURE----- From johnw at newartisans.com Mon Mar 2 18:01:35 2015 From: johnw at newartisans.com (John Wiegley) Date: Mon, 02 Mar 2015 12:01:35 -0600 Subject: Proposal: Add (<$>) to Prelude as part of the AMP in GHC 7.10-RC3 In-Reply-To: (David Feuer's message of "Tue, 24 Feb 2015 10:45:18 -0500") References: Message-ID: A hearty +1 for both. John From johnw at newartisans.com Mon Mar 2 18:02:28 2015 From: johnw at newartisans.com (John Wiegley) Date: Mon, 02 Mar 2015 12:02:28 -0600 Subject: Should foldl' be added to the post-"Plan FTP" Prelude In-Reply-To: (Alois Cochard's message of "Wed, 25 Feb 2015 21:26:42 +0100") References: <54ECE2B2.8060002@bitemyapp.com> Message-ID: +1 foldl'. John From asklingenberg at gmail.com Mon Mar 2 23:39:33 2015 From: asklingenberg at gmail.com (Andrew Klingenberg) Date: Mon, 02 Mar 2015 16:39:33 -0700 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: <54F4F4B5.2030301@gmail.com> I would be happy to assist with the Win32 library and/or be part of the "windows task force". I'm no Haskell expert but I do use GHC extensively on Windows for a few of our production apps. -- Andrew Klingenberg On 2015-02-28 21:39, Edward Kmett wrote: > We've had a lot of feedback over the last few months trying to get > clarification on the role of the core libraries committee, and on the > libraries@ process in general. In particular, Simon Peyton Jones asked > us in his own rather inimitable manner to make sure that we sat down > and started documenting things. After all, we've now been at this for > almost a year and a half, and have started to figure out what is > working and what isn't. > > In response to that feedback, we've recently taken the time to go > through and update the Library_submissions > page rather extensively > to better describe and refine the libraries@ process and better define > the role of the core libraries committee. > > Changes of note: > > * Up until now we've been using the rather ad hoc definition of "core > libraries" as libraries that come with the Haskell Platform and which > are subject to the libraries@ proposal process. We've recently taken > it upon ourselves to clarify this further. To that end we've updated > the Library_submissions > page with a detailed > summary of what libraries are considered "core" and why. > > * It was brought to our attention that figuring out even where to file > a bug report or feature request for a given library was a tricky > concern. To that end we've added information on how to find the > appropriate issue tracker to the form. > > Communication: > > There are two forms of potential communication breakdowns that we'd > like to address. > > We're still working on figuring out a more effective way to > communicate what changes are happening in the background out to the > community, lest we wind up with another situation like the > Foldable/Traversable Proposal, where it caught an appreciable segment > of the community unaware. We've started at least tracking issues that > impact modules defined in the Haskell report in GHC trac with > "report-impact", but we still have a lot more to do on this front. > > We have also been asked to help clarify what happens to a proposal > once it leaves the libraries@ mailing list, assuming that the proposal > is accepted by the maintainer. The issue was raised that it wasn't > clear when an issue had been dropped on the floor, and who has > responsibility to carry it forward at each stage along the way. To > that end, we've posted some basic responsiveness guidelines > to help. > We're not looking for a way to hold someone's feet to the fire, but > merely for a way to keep proposals from getting stuck in limbo as they > transition out of the libraries mailing list and into the hands of the > maintainers. > > Maintainership: > > In an effort to maintain a greater level of throughput on issues that > come along, we're trying to increase the number of projects that have > active maintainers. Some of these aren't necessarily core libraries, > but they are libraries that have been handed to the core libraries > committee for maintenance. > > A couple of weeks back we sought out an active maintainer for the > directory package, as it had accumulated several months worth of > backlogged tickets, most of which just needed a clear head to make an > informed decision about how to proceed. Phil Ruffwind and Elliot > Robinson stepped up to fill this gap, and have been making a rather > exciting amount of headway in clearing out the issue backlog, while > managing to give those issues the consideration they are due. > > Emboldened by this success, we have a few other packages with which > we'd like to do the same: > > * random > > We've had some truly excellent work done over the last couple of years > on how to deal with "splitting" a random number generator in a > cryptographically sound manner. I spent some time cleaning up a few > outstanding issues for this package personally over the summer, but > have not had nearly enough time to devote to the issue of how to > integrate the outcome of the recent research on splitting, while > simultaneously caring about performance and soundness. > > * unix > > We've had a number of issues accrete over time, particularly issues > that have to do with portability to lesser used platforms such as > OpenBSD. We've also had a lot of cooks in the kitchen, so the > documentation style for this library is all over the place. We could > use a solid maintainer for this package who is deeply familiar with > unix internals, and who, preferably would like to deal with bringing > some order to these cross platform concerns. > > * Win32 > > None of us on the current core libraries committee are /particularly/ > well versed in current windows issues. We have a new "windows task > force" as well. Would the task force -- or someone involved or who > would like to be involved in it -- be willing to pick this up and > carry the torch? > > * old-time, old-locale, haskell98 and haskell2010 > > The old-time and old-locale libraries are primarily maintained because > their contents are mentioned in the Haskell Report, which is/was > (mostly) implemented in the haskell98 and haskell2010 packages. Three > months ago, we determined to stop shipping these as boot libraries > with the GHC as a consequence of the Applicative-Monad Proposal. > (Issue #9590 ) While > Herbert Valerio Riedel recently started working on a "fully compliant" > version of the Haskell 2010 report, there is a reasonably large design > surface in that area, balancing between perfect compatibility and > pragmatic compatibility with other libraries. These libraries could > use a more active official maintainer. > > Thank you for your time. Please do not hesitate to contact me (or > reply) with questions, concerns, or thoughts. > > -Edward Kmett > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Tue Mar 3 07:32:09 2015 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 03 Mar 2015 07:32:09 +0000 Subject: Error -> Except migration Message-ID: <54F56379.4080103@earth.li> Hi, In recent versions of transformers, 'ErrorT' has been deprecated in favour of 'ExceptT': https://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-Error.html This doesn't seem like a trivial like-for-like replacement since the implementation of 'fail' is different - in ErrorT it produces an exception within the ErrorT itself, and in ExceptT it just calls fail in the underlying monad. Is there any guidance or simple trick to find if a program is relying on the old behaviour? Otherwise migrating could be rather painful/dangerous, particularly as tests often don't cover exceptional cases well. I've spent a while searching for past discussion of the change, but haven't found anything, so please do point me at anything relevant if this has already been discussed. Cheers, Ganesh From lemming at henning-thielemann.de Tue Mar 3 07:44:03 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 3 Mar 2015 08:44:03 +0100 (CET) Subject: Error -> Except migration In-Reply-To: <54F56379.4080103@earth.li> References: <54F56379.4080103@earth.li> Message-ID: On Tue, 3 Mar 2015, Ganesh Sittampalam wrote: > https://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-Error.html > > This doesn't seem like a trivial like-for-like replacement since the > implementation of 'fail' is different - in ErrorT it produces an > exception within the ErrorT itself, and in ExceptT it just calls fail in > the underlying monad. > > Is there any guidance or simple trick to find if a program is relying on > the old behaviour? Otherwise migrating could be rather > painful/dangerous, particularly as tests often don't cover exceptional > cases well. I think you should never call 'fail' in ExceptT, only throwE or mzero. That is, all pattern matches on the left hand side of '<-' must succeed. From simonpj at microsoft.com Tue Mar 3 08:32:35 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Mar 2015 08:32:35 +0000 Subject: Library_submissions and Call for Maintainers In-Reply-To: <54F4F4B5.2030301@gmail.com> References: <54F4F4B5.2030301@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBD3E1@DB3PRD3001MB020.064d.mgd.msft.net> Andrew Excellent, thank you! I've added you to the Windows Task Force list https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Andrew Klingenberg Sent: 02 March 2015 23:40 To: Edward Kmett; Haskell Libraries Subject: Re: Library_submissions and Call for Maintainers I would be happy to assist with the Win32 library and/or be part of the "windows task force". I'm no Haskell expert but I do use GHC extensively on Windows for a few of our production apps. -- Andrew Klingenberg On 2015-02-28 21:39, Edward Kmett wrote: We've had a lot of feedback over the last few months trying to get clarification on the role of the core libraries committee, and on the libraries@ process in general. In particular, Simon Peyton Jones asked us in his own rather inimitable manner to make sure that we sat down and started documenting things. After all, we've now been at this for almost a year and a half, and have started to figure out what is working and what isn't. In response to that feedback, we've recently taken the time to go through and update the Library_submissions page rather extensively to better describe and refine the libraries@ process and better define the role of the core libraries committee. Changes of note: * Up until now we've been using the rather ad hoc definition of "core libraries" as libraries that come with the Haskell Platform and which are subject to the libraries@ proposal process. We've recently taken it upon ourselves to clarify this further. To that end we've updated the Library_submissions page with a detailed summary of what libraries are considered "core" and why. * It was brought to our attention that figuring out even where to file a bug report or feature request for a given library was a tricky concern. To that end we've added information on how to find the appropriate issue tracker to the form. Communication: There are two forms of potential communication breakdowns that we'd like to address. We're still working on figuring out a more effective way to communicate what changes are happening in the background out to the community, lest we wind up with another situation like the Foldable/Traversable Proposal, where it caught an appreciable segment of the community unaware. We've started at least tracking issues that impact modules defined in the Haskell report in GHC trac with "report-impact", but we still have a lot more to do on this front. We have also been asked to help clarify what happens to a proposal once it leaves the libraries@ mailing list, assuming that the proposal is accepted by the maintainer. The issue was raised that it wasn't clear when an issue had been dropped on the floor, and who has responsibility to carry it forward at each stage along the way. To that end, we've posted some basic responsiveness guidelines to help. We're not looking for a way to hold someone's feet to the fire, but merely for a way to keep proposals from getting stuck in limbo as they transition out of the libraries mailing list and into the hands of the maintainers. Maintainership: In an effort to maintain a greater level of throughput on issues that come along, we're trying to increase the number of projects that have active maintainers. Some of these aren't necessarily core libraries, but they are libraries that have been handed to the core libraries committee for maintenance. A couple of weeks back we sought out an active maintainer for the directory package, as it had accumulated several months worth of backlogged tickets, most of which just needed a clear head to make an informed decision about how to proceed. Phil Ruffwind and Elliot Robinson stepped up to fill this gap, and have been making a rather exciting amount of headway in clearing out the issue backlog, while managing to give those issues the consideration they are due. Emboldened by this success, we have a few other packages with which we'd like to do the same: * random We've had some truly excellent work done over the last couple of years on how to deal with "splitting" a random number generator in a cryptographically sound manner. I spent some time cleaning up a few outstanding issues for this package personally over the summer, but have not had nearly enough time to devote to the issue of how to integrate the outcome of the recent research on splitting, while simultaneously caring about performance and soundness. * unix We've had a number of issues accrete over time, particularly issues that have to do with portability to lesser used platforms such as OpenBSD. We've also had a lot of cooks in the kitchen, so the documentation style for this library is all over the place. We could use a solid maintainer for this package who is deeply familiar with unix internals, and who, preferably would like to deal with bringing some order to these cross platform concerns. * Win32 None of us on the current core libraries committee are particularly well versed in current windows issues. We have a new "windows task force" as well. Would the task force -- or someone involved or who would like to be involved in it -- be willing to pick this up and carry the torch? * old-time, old-locale, haskell98 and haskell2010 The old-time and old-locale libraries are primarily maintained because their contents are mentioned in the Haskell Report, which is/was (mostly) implemented in the haskell98 and haskell2010 packages. Three months ago, we determined to stop shipping these as boot libraries with the GHC as a consequence of the Applicative-Monad Proposal. (Issue #9590) While Herbert Valerio Riedel recently started working on a "fully compliant" version of the Haskell 2010 report, there is a reasonably large design surface in that area, balancing between perfect compatibility and pragmatic compatibility with other libraries. These libraries could use a more active official maintainer. Thank you for your time. Please do not hesitate to contact me (or reply) with questions, concerns, or thoughts. -Edward Kmett _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganesh at earth.li Tue Mar 3 12:29:32 2015 From: ganesh at earth.li (Ganesh Sittampalam) Date: Tue, 03 Mar 2015 12:29:32 +0000 Subject: Error -> Except migration In-Reply-To: References: <54F56379.4080103@earth.li> Message-ID: <54F5A92C.9040801@earth.li> On 03/03/2015 07:44, Henning Thielemann wrote: > > On Tue, 3 Mar 2015, Ganesh Sittampalam wrote: > >> https://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-Error.html >> >> >> This doesn't seem like a trivial like-for-like replacement since the >> implementation of 'fail' is different - in ErrorT it produces an >> exception within the ErrorT itself, and in ExceptT it just calls fail in >> the underlying monad. >> >> Is there any guidance or simple trick to find if a program is relying on >> the old behaviour? Otherwise migrating could be rather >> painful/dangerous, particularly as tests often don't cover exceptional >> cases well. > > > I think you should never call 'fail' in ExceptT, only throwE or mzero. > That is, all pattern matches on the left hand side of '<-' must succeed. What I need is to find all the *existing* calls to fail in my currently working ErrorT code so I can remove them. Ganesh From rf at rufflewind.com Tue Mar 3 18:35:27 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 3 Mar 2015 13:35:27 -0500 Subject: On the scope of 'directory' (and which issue tracker to use) Message-ID: Looking at the current API, it seems that the 'directory' library has been extended to more than just mere directory-related operations: it includes several file-related utilities as well. It looks to me that 'directory' has become a place for consolidating filesystem-related operations for *nix and Windows platforms. Given the state of things, would it be more appropriate to call it a "platform-agnostic library for filesystem operations" rather than a "library for directory manipulation"? (Of course, the name of the library and its modules would remain slightly misleading but oh well.) On an unrelated issue, seeing as most of the issues are on GitHub rather than Trac (and I personally find the former simpler to use) perhaps the .cabal file should point to the GitHub issue tracker instead? -- Phil From ekmett at gmail.com Tue Mar 3 18:39:43 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 3 Mar 2015 13:39:43 -0500 Subject: On the scope of 'directory' (and which issue tracker to use) In-Reply-To: References: Message-ID: Pointing the issue tracker to the correct place makes a lot of sense. Same with changing the description. -Edward On Tue, Mar 3, 2015 at 1:35 PM, Phil Ruffwind wrote: > Looking at the current API, it seems that the 'directory' library has been > extended to more than just mere directory-related operations: it includes > several file-related utilities as well. It looks to me that 'directory' > has > become a place for consolidating filesystem-related operations for *nix and > Windows platforms. > > Given the state of things, would it be more appropriate to call it a > "platform-agnostic library for filesystem operations" rather than a > "library > for directory manipulation"? (Of course, the name of the library and its > modules would remain slightly misleading but oh well.) > > On an unrelated issue, seeing as most of the issues are on GitHub rather > than > Trac (and I personally find the former simpler to use) perhaps the .cabal > file > should point to the GitHub issue tracker instead? > > -- > Phil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Mar 5 22:59:23 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 5 Mar 2015 17:59:23 -0500 Subject: Expand the Data.Set API Message-ID: There are a few rather conspicuously missing features: 1. A way to take the intersection of a list of sets. This shouldn't really be a big deal, and it already exists for unions, but the intersection version should probably sort the sets by size before folding, or otherwise try to do something smart. 2. A way to insert an element if an == one is not already present (insert replaces an existing one with a new one). Currently, as far as I can tell, this can only be done using either if e `member` s then s else insert e s which potentially descends the tree twice for no reason or s `union` singleton e which is documented as being O(|s|+1), although I wouldn't be shocked if the documentation were too pessimistic in this case. 3. A way to delete an element and simultaneously find out whether it was in the set. David Feuer From johnw at newartisans.com Thu Mar 5 23:15:35 2015 From: johnw at newartisans.com (John Wiegley) Date: Thu, 05 Mar 2015 17:15:35 -0600 Subject: Expand the Data.Set API In-Reply-To: (David Feuer's message of "Thu, 5 Mar 2015 17:59:23 -0500") References: Message-ID: >>>>> David Feuer writes: > There are a few rather conspicuously missing features: +1 to all points. John From cam at uptoisomorphism.net Fri Mar 6 00:17:55 2015 From: cam at uptoisomorphism.net (Casey McCann) Date: Thu, 5 Mar 2015 19:17:55 -0500 Subject: Expand the Data.Set API In-Reply-To: References: Message-ID: On Thu, Mar 5, 2015 at 5:59 PM, David Feuer wrote: > There are a few rather conspicuously missing features: > > 1. A way to take the intersection of a list of sets. This shouldn't > really be a big deal, and it already exists for unions, but the > intersection version should probably sort the sets by size before > folding, or otherwise try to do something smart. Incidentally, having "unions" but not "intersections" is also true of IntSet, Map, and IntMap. Adding it to all would probably be good for consistency if nothing else, unless there's some reason not to. > 3. A way to delete an element and simultaneously find out whether it > was in the set. Likewise here, I believe, though I may be forgetting something. I'm pretty sure your second point is only missing-but-useful for Data.Set, though. - C. From oleg.grenrus at iki.fi Fri Mar 6 08:27:32 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 6 Mar 2015 10:27:32 +0200 Subject: ApplicativeZip Message-ID: <0E1FA052-788C-4AB1-8A79-C43C04DC87CA@iki.fi> After Edward Kmett mentioned that we should add MonadZip to Data.Monoid instances, that got me thinking about: Why we don?t have ApplicativeZip? class Applicative f => ApplicativeZip f where {-# MINIMAL azip | azipWith #-} azip :: m a -> m b -> m (a,b) azip = azipWith (,) -- This is `liftA2` but can be done more efficiently for some instances (is it true?) azipWith :: (a -> b -> c) -> m a -> m b -> m c azipWith f = azip (uncurry f) aunzip :: m (a,b) -> (m a, m b) aunzip mab = (fst <$> mab, liftM <$> mab) and class (Monad m, ApplicativeZip m) => MonadZip m where mzip :: m a -> m b -> m (a,b) mzip = azip mzipWith :: (a -> b -> c) -> m a -> m b -> m c mzipWith = azipWith munzip :: m (a,b) -> (m a, m b) munzip = aunzip IMHO that should been done during AMP-reform, sorry if this topic is already discussed. - Oleg -------------- 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 mail at joachim-breitner.de Fri Mar 6 08:42:28 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Mar 2015 09:42:28 +0100 Subject: Expand the Data.Set API In-Reply-To: References: Message-ID: <1425631348.1335.6.camel@joachim-breitner.de> Hi, Am Donnerstag, den 05.03.2015, 17:59 -0500 schrieb David Feuer: > 1. A way to take the intersection of a list of sets. This shouldn't > really be a big deal, and it already exists for unions, but the > intersection version should probably sort the sets by size before > folding, or otherwise try to do something smart. +1 > 2. A way to insert an element if an == one is not already present > (insert replaces an existing one with a new one). Currently, as far as > I can tell, this can only be done using either > > if e `member` s then s else insert e s > which potentially descends the tree twice for no reason > > or > > s `union` singleton e > > which is documented as being O(|s|+1), although I wouldn't be shocked > if the documentation were too pessimistic in this case. I?m doubtful about that one. This is only needed if == is not ?the right equality?, in which case a Set might be the wrong data type. Do we want to advocate that style? Also, it will make everyone wonder ?do I need insert or theOtherInsert?, making the API a bit less concise and quick to grasp. Since "s `union` singleton e" does the right thing with almost the right performance, maybe that?s sufficient? > 3. A way to delete an element and simultaneously find out whether it > was in the set. +1, possibly with the type a -> Set a -> Maybe (a, Set a) to get the remaining set as well. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-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 david.feuer at gmail.com Fri Mar 6 08:46:17 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 6 Mar 2015 03:46:17 -0500 Subject: Expand the Data.Set API In-Reply-To: <1425631348.1335.6.camel@joachim-breitner.de> References: <1425631348.1335.6.camel@joachim-breitner.de> Message-ID: Regarding (2), I was thinking about situations where sharing is an issue. Even if == is the right equality, you may want to settle on a single copy. That would also suggest a version of member that returns a Maybe instead of a Bool. On Mar 6, 2015 3:42 AM, "Joachim Breitner" wrote: > Hi, > > > Am Donnerstag, den 05.03.2015, 17:59 -0500 schrieb David Feuer: > > 1. A way to take the intersection of a list of sets. This shouldn't > > really be a big deal, and it already exists for unions, but the > > intersection version should probably sort the sets by size before > > folding, or otherwise try to do something smart. > > +1 > > > 2. A way to insert an element if an == one is not already present > > (insert replaces an existing one with a new one). Currently, as far as > > I can tell, this can only be done using either > > > > if e `member` s then s else insert e s > > which potentially descends the tree twice for no reason > > > > or > > > > s `union` singleton e > > > > which is documented as being O(|s|+1), although I wouldn't be shocked > > if the documentation were too pessimistic in this case. > > I?m doubtful about that one. > > This is only needed if == is not ?the right equality?, in which case a > Set might be the wrong data type. Do we want to advocate that style? > > Also, it will make everyone wonder ?do I need insert or theOtherInsert?, > making the API a bit less concise and quick to grasp. > > Since "s `union` singleton e" does the right thing with almost the right > performance, maybe that?s sufficient? > > > 3. A way to delete an element and simultaneously find out whether it > > was in the set. > > +1, possibly with the type > a -> Set a -> Maybe (a, Set a) > to get the remaining set as well. > > Greetings, > Joachim > > > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Mar 6 09:31:44 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 6 Mar 2015 10:31:44 +0100 (CET) Subject: Expand the Data.Set API In-Reply-To: <1425631348.1335.6.camel@joachim-breitner.de> References: <1425631348.1335.6.camel@joachim-breitner.de> Message-ID: On Fri, 6 Mar 2015, Joachim Breitner wrote: >> 2. A way to insert an element if an == one is not already present >> (insert replaces an existing one with a new one). Currently, as far as >> I can tell, this can only be done using either >> >> if e `member` s then s else insert e s >> which potentially descends the tree twice for no reason >> >> or >> >> s `union` singleton e >> >> which is documented as being O(|s|+1), although I wouldn't be shocked >> if the documentation were too pessimistic in this case. > > I?m doubtful about that one. > > This is only needed if == is not ?the right equality?, in which case a > Set might be the wrong data type. Do we want to advocate that style? We should use Map for element types that contain data which is irrelevant to the order. > Since "s `union` singleton e" does the right thing with almost the right > performance, maybe that?s sufficient? I guess he prefered something like runtime log |s| + 1. >> 3. A way to delete an element and simultaneously find out whether it >> was in the set. > > +1, possibly with the type > a -> Set a -> Maybe (a, Set a) > to get the remaining set as well. This would be consistent to minView and maxView. Until there is such a delete function, splitMember might be used in a work-around. From ivan.miljenovic at gmail.com Fri Mar 6 11:13:53 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 6 Mar 2015 22:13:53 +1100 Subject: fgl-5.5.0.1 In-Reply-To: References: <54E1EF0F.5010705@jacobs-university.de> Message-ID: It took me longer than I expected, but I've migrated fgl over to GitHub and added in a bunch of changes/fixups (including hopefully GHC 7.10 compatibility): https://github.com/haskell/fgl Can people please check this (especially since I don't have 7.10 and can't actually test it); I'm also unsure if some of these changes (e.g. data -> newtype and removal of data type contexts) requires a major version bump. If there aren't any problems, I'll make a release over the weekend. On 17 February 2015 at 13:18, Ivan Lazar Miljenovic wrote: > (And I forgot to mention I'll re-check this over the next few days.) > > On 17 February 2015 at 13:18, Ivan Lazar Miljenovic > wrote: >> Sure; I just didn't want to have the possibility that I released a >> 7.10-compatible release only to find that another was needed >> (admittedly, I haven't actually examined whether this would be the >> case due to too-monomorphic usage of stuff that will be in FTP). >> >> On 17 February 2015 at 13:08, Carter Schonwald >> wrote: >>> hey ivan, AMP will be required in 7.10 no matter what the outcome of the FTP >>> survey, which is mostly about changes to foldable and whether foldable + >>> traversable will be in prelude >>> cheers >>> -Carter >>> >>> On Mon, Feb 16, 2015 at 6:47 PM, Ivan Lazar Miljenovic >>> wrote: >>>> >>>> I've received several requests for this, but especially because of the >>>> burning bridges proposal and the ongoing survey about whether it >>>> should be included in 7.10 I'm wanting to hold back on doing a >>>> 7.10-compatible release until I know what will actually be required. >>>> >>>> On 17 February 2015 at 00:22, C Maeder >>>> wrote: >>>> > Hi Ivan, >>>> > >>>> > could you make a new release of fgl that works with ghc-7.10? >>>> > >>>> > I could compile it locally after the following changes: >>>> > >>>> > Data/Graph/Inductive/Query/Monad.hs >>>> > >>>> > +import Control.Applicative >>>> > +import Control.Monad (ap, liftM) >>>> > >>>> > +instance Monad m => Functor (GT m g) where >>>> > + fmap = liftM >>>> > + >>>> > +instance Monad m => Applicative (GT m g) where >>>> > + pure = return >>>> > + (<*>) = ap >>>> > >>>> > Data/Graph/Inductive/Monad/IOArray.hs >>>> > >>>> > -{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} >>>> > +{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FlexibleContexts >>>> > #-} >>>> > >>>> > I'm not sure why FlexibleContexts is now needed and I'm not sure how the >>>> > package version number should change. >>>> > >>>> > Cheers Christian >>>> >>>> >>>> >>>> -- >>>> Ivan Lazar Miljenovic >>>> Ivan.Miljenovic at gmail.com >>>> http://IvanMiljenovic.wordpress.com >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From svenpanne at gmail.com Fri Mar 6 11:42:53 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 6 Mar 2015 12:42:53 +0100 Subject: fgl-5.5.0.1 In-Reply-To: References: <54E1EF0F.5010705@jacobs-university.de> Message-ID: 2015-03-06 12:13 GMT+01:00 Ivan Lazar Miljenovic : > It took me longer than I expected, but I've migrated fgl over to > GitHub and added in a bunch of changes/fixups (including hopefully GHC > 7.10 compatibility): https://github.com/haskell/fgl [...] If you have your project already on github, testing should be easy, see: https://github.com/hvr/multi-ghc-travis. From hvr at gnu.org Fri Mar 6 11:43:57 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 06 Mar 2015 12:43:57 +0100 Subject: Expand the Data.Set API In-Reply-To: (David Feuer's message of "Thu, 5 Mar 2015 17:59:23 -0500") References: Message-ID: <87k2yus64i.fsf@gnu.org> On 2015-03-05 at 23:59:23 +0100, David Feuer wrote: > There are a few rather conspicuously missing features: [...] > 2. A way to insert an element if an == one is not already present > (insert replaces an existing one with a new one). Currently, as far as > I can tell, this can only be done using either > > if e `member` s then s else insert e s > which potentially descends the tree twice for no reason > > or > > s `union` singleton e > > which is documented as being O(|s|+1), although I wouldn't be shocked > if the documentation were too pessimistic in this case. > > 3. A way to delete an element and simultaneously find out whether it > was in the set. Maybe (2) and (3) can be combined, c.f. https://github.com/gregorycollins/hashtables/issues/6#issuecomment-37523794 there's related tickets in unordered-containers too: https://github.com/tibbe/unordered-containers/issues/93 (even though those are for associative arrays, it'd be good if we could come up with a coherent story for these operations rather than ending up with subtly differently named/typed operations -- assuming it makes sense to find a uniform scheme) Cheers, hvr From dominic at steinitz.org Fri Mar 6 18:29:53 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Fri, 6 Mar 2015 18:29:53 +0000 (UTC) Subject: =?utf-8?b?TGlicmFyeV9zdWJtaXNzaW9ucw==?= and Call for Maintainers References: Message-ID: Gershom B gmail.com> writes: > I am not volunteering to work on such a project, but it seems like > it could not only be worthwhile, but quite a bit of fun for somebody > with the right > inclination. [1]?http://dl.acm.org/citation.cfm?id=2660195&CFID=630640078&CFTOKEN=34009864 I'm happy to take a look but I can't find a copy of the paper you reference. From ezyang at mit.edu Fri Mar 6 21:38:25 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 06 Mar 2015 13:38:25 -0800 Subject: Data.Graph (and Data.Tree) improvements Message-ID: <1425676423-sup-291@sabre> Data.Graph has always been a bit of an unloved module in containers. However, at GHC HQ the graph has always been a bit of an important data type, and we've been maintaining basically another version of the module under the name Digraph. I was refactoring this module to use Data.Graph and I noticed that there were a few functions which were conspicuously missing from the module proper. So here they are: For Data.Graph: - Generalized reachable :: Graph -> [Vertex] -> [Vertex] (compare to reachable :: Graph -> Vertex -> [Vertex] - Returns an undirected version of a graph which, for any edge a -> b, an edge b -> a also exists. undirected :: Graph -> Graph - Extract a list of groups of elements of a graph such that each group has no dependence except on nodes in previous groups (i.e. they may not depend on nodes in their own group) such that the groups are maximal. No solution exists for cyclic graphs vertexGroups :: Graph -> [[Vertex]] For Data.Tree - preorderF :: Forest a -> [a] (or perhaps flattenF, to keep naming consistent with existing flatten :: Tree a -> [a] which does a preorder) Furthermore, we have a few "low level" functions implementing algorithms for classifying edges, finding connected and biconnected components that were contributed by Sigbjorn Finne in 1997, although GHC does not use them. Finally, I think GHC's node-parametrized variant of graphs (to which it gives the name 'Graph', as opposed to Data.Graph style graphs which it calls 'IntGraph'; is far more useful to clients: data Graph node = Graph { gr_int_graph :: IntGraph, gr_vertex_to_node :: Vertex -> node, gr_node_to_vertex :: node -> Maybe Vertex } and I think it is well worth considering implementing this is the standard library. If no one else, GHC will happily use such an implementation. Thanks, Edward From haskell at benmachine.co.uk Sat Mar 7 14:43:34 2015 From: haskell at benmachine.co.uk (Ben Millwood) Date: Sat, 7 Mar 2015 14:43:34 +0000 Subject: Expand the Data.Set API In-Reply-To: References: Message-ID: <20150307144334.GA192946@srcf.ucam.org> On Thu, Mar 05, 2015 at 05:59:23PM -0500, David Feuer wrote: >1. A way to take the intersection of a list of sets. This shouldn't >really be a big deal, and it already exists for unions, but the >intersection version should probably sort the sets by size before >folding, or otherwise try to do something smart. I would guess the major reason intersection is more awkward than union is that the intersection of the empty list is not defined (there's no identity for the intersection operation), whereas for unions that problem doesn't exist. I don't think that's a dealbreaker -- foldr1 exists, after all -- but it does open a discussion about whether we want to error on the empty list or force the user to provide a first element or something. From ekmett at gmail.com Sat Mar 7 19:39:47 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 7 Mar 2015 14:39:47 -0500 Subject: Missing instances for Eq1 (Const a), Ord1 (Const a), Show1 (Const a), Ord1 (Const a) Message-ID: I was looking at switching a chunk of my code over from prelude-extras to transformers 0.5, but the classes in http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Data-Functor-Classes.html are currently missing instances for Control.Applicative.Const. =/ -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sat Mar 7 23:08:11 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 08 Mar 2015 00:08:11 +0100 Subject: Should foldl' be added to the post-"Plan FTP" Prelude References: <20150226.093145.1386058826244716294.kazu@iij.ad.jp> Message-ID: David Feuer wrote: > FTP sets up the expectation that foldl has a specific relationship to > foldMap. How does foldl have a more specific relationship with foldMap than foldl'? Both are currently methods of class Foldable, BTW. > I suppose you could go against that, I have not yet formed an opinion. I just want to understand your response which remains cryptic to me. > and also break any code > relying on the current foldl semantics, but I'd personally be very much > opposed to that. Fair enough, but a different matter. Cheers Ben > On Mar 1, 2015 5:13 PM, "Ben Franksen" wrote: > >> Why not? >> >> David Feuer wrote: >> > No, that is not a way now that we have FTP. >> > >> > On Wed, Feb 25, 2015 at 7:31 PM, Kazu Yamamoto wrote: >> >>> I would love to have foldl' as part of the Prelude. I use it quite >> >>> frequently and it seems like a beginner trap to have foldl but not >> >>> foldl' (which is almost always the better choice). I see that foldMap >> >>> has been added (in addition to all of Monoid and Traversable), why >> >>> was foldl' left out? >> >> >> >> That is one way but I think another way is to make foldl strict: >> >> >> >> http://www.well-typed.com/blog/90/ >> >> >> >> I'm tired of explaining the difference of foldl and foldl' to >> >> beginners. :-) >> >> >> >> --Kazu From david.feuer at gmail.com Sun Mar 8 04:33:13 2015 From: david.feuer at gmail.com (David Feuer) Date: Sat, 7 Mar 2015 23:33:13 -0500 Subject: Should foldl' be added to the post-"Plan FTP" Prelude In-Reply-To: References: <20150226.093145.1386058826244716294.kazu@iij.ad.jp> Message-ID: On Sat, Mar 7, 2015 at 6:08 PM, Ben Franksen wrote: > David Feuer wrote: >> FTP sets up the expectation that foldl has a specific relationship to >> foldMap. > > How does foldl have a more specific relationship with foldMap than foldl'? > Both are currently methods of class Foldable, BTW. Yes, and each is expected to have a specific relationship to foldMap. Changing the foldl for lists breaks that. David From oleg.grenrus at iki.fi Sun Mar 8 18:17:14 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 8 Mar 2015 20:17:14 +0200 Subject: ApplicativeZip In-Reply-To: References: <0E1FA052-788C-4AB1-8A79-C43C04DC87CA@iki.fi> Message-ID: After thinking for a while (and looking onto MonadZip [] instance), I realised that: `MonadZip []` is the same as `Applicative ZIpList`, not `Applicative []` I guess that answers my question. Also Information preservation law: liftM (const ()) ma = liftM (const ()) mb excludes the default implementation of munzip for non-deterministic computations, as the information is ?multiplied". The naturality law follows from Applicative laws. ? After some thinking (and re-reading the "Monadic zipping (used for monad comprehensions)? comment in the documentation), this is obvious. But I?ll try to make a documentation improvement patch, so no-one have to wonder this that much again. - Oleg > On 06 Mar 2015, at 10:30, David Feuer wrote: > > It was already discussed, I think, but I don't remember the conclusion! > > On Mar 6, 2015 3:27 AM, "Oleg Grenrus" wrote: > After Edward Kmett mentioned that we should add MonadZip to Data.Monoid instances, that got me thinking about: > > Why we don?t have ApplicativeZip? > > class Applicative f => ApplicativeZip f where > {-# MINIMAL azip | azipWith #-} > azip :: m a -> m b -> m (a,b) > azip = azipWith (,) > > -- This is `liftA2` but can be done more efficiently for some instances (is it true?) > azipWith :: (a -> b -> c) -> m a -> m b -> m c > azipWith f = azip (uncurry f) > > aunzip :: m (a,b) -> (m a, m b) > aunzip mab = (fst <$> mab, liftM <$> mab) > > and > > class (Monad m, ApplicativeZip m) => MonadZip m where > mzip :: m a -> m b -> m (a,b) > mzip = azip > > mzipWith :: (a -> b -> c) -> m a -> m b -> m c > mzipWith = azipWith > > munzip :: m (a,b) -> (m a, m b) > munzip = aunzip > > IMHO that should been done during AMP-reform, sorry if this topic is already discussed. > > - Oleg > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- 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 me at philscotted.com Sun Mar 8 18:29:20 2015 From: me at philscotted.com (Phil Scott) Date: Sun, 08 Mar 2015 18:29:20 +0000 Subject: Add MonadError () Maybe Message-ID: <54FC9500.6070202@philscotted.com> With Maybe being isomorphic to Either (), can we have the instance MonadError () Maybe? I'm interested in the MonadError class, and write generic code against it, and would like it to work with Maybe. From R.Paterson at city.ac.uk Sun Mar 8 18:33:33 2015 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Sun, 8 Mar 2015 18:33:33 +0000 Subject: Missing instances for Eq1 (Const a), Ord1 (Const a), Show1 (Const a), Ord1 (Const a) In-Reply-To: References: Message-ID: <20150308183333.GA10498@city.ac.uk> On Sat, Mar 07, 2015 at 02:39:47PM -0500, Edward Kmett wrote: > I was looking at switching a chunk of my code over from prelude-extras to > transformers 0.5, but the classes in > > http://hackage.haskell.org/package/transformers-0.4.2.0/docs/ > Data-Functor-Classes.html > > are currently missing instances for Control.Applicative.Const. =/ added now From ekmett at gmail.com Sun Mar 8 20:55:33 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 8 Mar 2015 16:55:33 -0400 Subject: Add MonadError () Maybe In-Reply-To: <54FC9500.6070202@philscotted.com> References: <54FC9500.6070202@philscotted.com> Message-ID: +1 from me. It makes sense. -Edward On Sun, Mar 8, 2015 at 2:29 PM, Phil Scott wrote: > With Maybe being isomorphic to Either (), can we have the instance > MonadError () Maybe? > > I'm interested in the MonadError class, and write generic code against it, > and would like it to work with Maybe. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Mar 9 04:43:10 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 9 Mar 2015 15:43:10 +1100 Subject: ANNOUNCE: fgl 5.5.1.0 Message-ID: I'm pleased to announce that - after being pestered about it for the past few months ;-) - I've released a new version of the Functional Graph Library that should* now be compatible with GHC 7.10. fgl is now developed on GitHub: https://github.com/haskell/fgl * In that I can't test it on my own machines -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From andreas.abel at ifi.lmu.de Mon Mar 9 14:23:13 2015 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Mon, 09 Mar 2015 15:23:13 +0100 Subject: Add MonadError () Maybe In-Reply-To: References: <54FC9500.6070202@philscotted.com> Message-ID: <54FDACD1.1070205@ifi.lmu.de> +1. --Andreas On 08.03.2015 21:55, Edward Kmett wrote: > +1 from me. > > It makes sense. > > -Edward > > On Sun, Mar 8, 2015 at 2:29 PM, Phil Scott > wrote: > > With Maybe being isomorphic to Either (), can we have the instance > MonadError () Maybe? > > I'm interested in the MonadError class, and write generic code > against it, and would like it to work with Maybe. > > _________________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-__bin/mailman/listinfo/libraries > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From ekmett at gmail.com Tue Mar 10 21:26:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 10 Mar 2015 17:26:10 -0400 Subject: Proposal: Add (<$>) to Prelude as part of the AMP in GHC 7.10-RC3 In-Reply-To: References: Message-ID: As the results were almost unanimous, we've merged both. [1][2][3] This was mentioned in the GHC Status Update today and they should appear in RC3. -Edward [1] : https://ghc.haskell.org/trac/ghc/ticket/10113 [2] : https://git.haskell.org/ghc.git/commitdiff/eb3661f2b9f8472f3714774126ebe1183484dd85 [3] : https://ghc.haskell.org/trac/ghc/changeset/479523f3c37894d63352f1718e06696f3ed63143/ghc On Mon, Mar 2, 2015 at 1:01 PM, John Wiegley wrote: > A hearty +1 for both. > > John > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Mar 11 15:14:18 2015 From: david.feuer at gmail.com (David Feuer) Date: Wed, 11 Mar 2015 11:14:18 -0400 Subject: Proposal: Export cycleN from Data.Sequence Message-ID: Yesterday I rewrote `*>` for Data.Sequence (again), using an internal function cycleN :: Int -> Seq a -> Seq a The name of the function is based on that of Data.Sequence.iterateN. cycleN takes a sequence and cycles it as many times as requested: cycleN 0 $ fromList [1,2] = [] cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] The function is written to maximize sharing in the result sequence and to minimize construction time. Specifically, cycleN n xs should take something like O(|xs| + log n) space (of which all but O(log |xs| + log n) is shared with the structure of xs) and O(log |xs| + log n) time. With current (on GitHub) Data.Sequence exports, the only way to get this functionality with these time and space bounds is to combine replicate with *> : cycleN n xs = replicate n () *> xs This strikes me as a bit unpleasant. David From fumiexcel at gmail.com Fri Mar 13 09:32:05 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Fri, 13 Mar 2015 18:32:05 +0900 Subject: Generalizing map? Message-ID: A dozen of functions like concat, foldr, mapM, have been generalized through BBP. Then, why do we leave `map` just for lists? Obviously `map` can be generalized, so map :: Functor f => (a -> b) -> f a -> f b map = fmap The current definition of `map` looks too special to be a special case of mapM (map f = runIdentity . mapM (Identity . f)). -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.y.volkov at gmail.com Fri Mar 13 09:35:19 2015 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Fri, 13 Mar 2015 12:35:19 +0300 Subject: Generalizing map? In-Reply-To: References: Message-ID: I can't +1 this enough to express how much I desire that change! 2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita : > A dozen of functions like concat, foldr, mapM, have been generalized > through BBP. > > Then, why do we leave `map` just for lists? Obviously `map` can be > generalized, so > > map :: Functor f => (a -> b) -> f a -> f b > map = fmap > > The current definition of `map` looks too special to be a special case of > mapM (map f = runIdentity . mapM (Identity . f)). > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Fri Mar 13 09:40:27 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Fri, 13 Mar 2015 10:40:27 +0100 Subject: Generalizing map? In-Reply-To: References: Message-ID: Why is this change so important when fmap is already in the prelude? Erik On Fri, Mar 13, 2015 at 10:35 AM, Nikita Volkov wrote: > I can't +1 this enough to express how much I desire that change! > > 2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita : >> >> A dozen of functions like concat, foldr, mapM, have been generalized >> through BBP. >> >> Then, why do we leave `map` just for lists? Obviously `map` can be >> generalized, so >> >> map :: Functor f => (a -> b) -> f a -> f b >> map = fmap >> >> The current definition of `map` looks too special to be a special case of >> mapM (map f = runIdentity . mapM (Identity . f)). >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From nikita.y.volkov at gmail.com Fri Mar 13 10:00:34 2015 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Fri, 13 Mar 2015 13:00:34 +0300 Subject: Generalizing map? In-Reply-To: References: Message-ID: I don't know any function that is used more frequently. The only argument for the existence of the specialised `map` that I've heard is that it's supposed to make the type signatures simpler for the newbies. I find this argument outright wrong. The simplicity of the Prelude ship has sailed long ago. With the already scheduled changes it's gonna sail twice as far. Also I find the sole premise of trying to look simple to the newbies a waste of effort and consistency of API. 2015-03-13 12:40 GMT+03:00 Erik Hesselink : > Why is this change so important when fmap is already in the prelude? > > Erik > > On Fri, Mar 13, 2015 at 10:35 AM, Nikita Volkov > wrote: > > I can't +1 this enough to express how much I desire that change! > > > > 2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita : > >> > >> A dozen of functions like concat, foldr, mapM, have been generalized > >> through BBP. > >> > >> Then, why do we leave `map` just for lists? Obviously `map` can be > >> generalized, so > >> > >> map :: Functor f => (a -> b) -> f a -> f b > >> map = fmap > >> > >> The current definition of `map` looks too special to be a special case > of > >> mapM (map f = runIdentity . mapM (Identity . f)). > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Fri Mar 13 10:07:35 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 13 Mar 2015 05:07:35 -0500 Subject: Generalizing map? In-Reply-To: References: Message-ID: Strong, but self-consciously hopeless, (+1) from me. Existence of the redundant `map` has confused many new people I've worked with. It was based on an early understanding of what was confusing or not to new people. `fmap` can be specialized by an explicit type - you can elide the existence of Functor from learning materials until it's appropriate without having API redundancy. Haskell 1.4 had it right to begin with. The real argument against this change would the ambiguous type errors that would result. Compile-time type error but easily fixed with an explicit type annotation. I'm not an imaginative person, but I can't think of any other problems at this time. On Fri, Mar 13, 2015 at 4:35 AM, Nikita Volkov wrote: > I can't +1 this enough to express how much I desire that change! > > 2015-03-13 12:32 GMT+03:00 Fumiaki Kinoshita : > >> A dozen of functions like concat, foldr, mapM, have been generalized >> through BBP. >> >> Then, why do we leave `map` just for lists? Obviously `map` can be >> generalized, so >> >> map :: Functor f => (a -> b) -> f a -> f b >> map = fmap >> >> The current definition of `map` looks too special to be a special case of >> mapM (map f = runIdentity . mapM (Identity . f)). >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Fri Mar 13 10:52:04 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 13 Mar 2015 11:52:04 +0100 Subject: Generalizing map? In-Reply-To: References: Message-ID: <5502C154.8050009@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 +1. Although I would prefer the far more radical (and thus far more unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlUCwVIACgkQRtClrXBQc7XSyAD/S9z64F6v1HMdp7WXYH59dKmj +xVnZkoYBe58h2u7ok0A/3c5uAlZTigDLWKaeW9uMzLVLRn6SXf4XrlIQhv11Fz9 =NPlO -----END PGP SIGNATURE----- From nikita.y.volkov at gmail.com Fri Mar 13 11:41:46 2015 From: nikita.y.volkov at gmail.com (Nikita Volkov) Date: Fri, 13 Mar 2015 14:41:46 +0300 Subject: Generalizing map? In-Reply-To: <5502C154.8050009@plaimi.net> References: <5502C154.8050009@plaimi.net> Message-ID: > Although I would prefer the far more radical (and thus far more unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. I'd vote for that too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Mar 13 13:44:40 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 13 Mar 2015 09:44:40 -0400 Subject: Generalizing map? In-Reply-To: References: Message-ID: We need to be very careful to make sure we don't break list fusion. map is one of relatively few functions that are both "good consumers" and "good producers". This makes it especially sensitive to anything affecting simplification. Making map be fmap means that it will not be recognized as the thing that should fuse until later in the process, and we want to be sure that doesn't kill all the benchmarks. -- David Feuer If you like my advice, please hire me. On Fri, Mar 13, 2015 at 5:32 AM, Fumiaki Kinoshita wrote: > A dozen of functions like concat, foldr, mapM, have been generalized through > BBP. > > Then, why do we leave `map` just for lists? Obviously `map` can be > generalized, so > > map :: Functor f => (a -> b) -> f a -> f b > map = fmap > > The current definition of `map` looks too special to be a special case of > mapM (map f = runIdentity . mapM (Identity . f)). > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From carter.schonwald at gmail.com Fri Mar 13 15:06:03 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 13 Mar 2015 11:06:03 -0400 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: Earlier versions of the haskell standard originally named fmap map. It was only as of haskell 1.4 or so that what was then map got renamed to map I think the only technical objection is making sure that theres no performance regressions wrt applicable fusion opportunities. Subject to that, hearty plus one to fmap reclaiming map :) > Although I would prefer the far more radical (and thus far more unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. I'd vote for that too. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Fri Mar 13 17:29:36 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Fri, 13 Mar 2015 10:29:36 -0700 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: While I love the idea of gradually "cleaning up" the Prelude, I have a few problems with this proposal. 1. This will break documentation *everywhere*. This will make the majority of beginner tutorials flag out *wrong*. This is already happening a bit with type signatures due to BBP, but my intuition tells me that `map` and `fmap` are even more commonly used in tutorials, and will break even more. 2. If we're willing to make changes to `map`, are there other things that we want to generalize or clean up? Rather than a dozen small email threads about "add this function" or "generalize this", perhaps we could instead take a good hard look at the Prelude, and decide on a long-scale migration plan. What do we want in the long run? How do we accomplish it with least breakage? What sort of tooling can we develop -- language extensions, Haskell preprocessors, etc -- that could make a migration to a cleaner prelude as easy as possible? Overall, I am a huge fan of striving towards a more beautiful Prelude, but I want it done in a principled way. I fear that if these sorts of threads are the way it happens, we will hear from a very select few among the Haskell community, and the spectacle of BBP may repeat itself. 3. This would break a lot of code, I think. My intuition tells me that using `map` instead of `fmap` is often used to specify types -- that is, many places will be ambiguous if we generalize map. So, fairly strong -1 from me on this specific proposal in its current form. However, if we want to continue cleaning up Prelude in a more principled way, I would strongly support that. How about something like this? 1. Gather a group of people interested in designing a proposal to clean up the Haskell prelude -- NPP, the New Prelude Proposal. 2. Detail an exhaustive list of changes we *could* want to make to the current Prelude. 3. Decide which of these changes are feasible to make in the near future (next five years). 4. Decide how we could make each of the changes, specifically figuring out how much code would break, how the change could be made to avoid breakage, and so on. 5. Organize the implementation of tools and extensions necessary to minimize breakage, and slowly work towards fixing our Prelude. That said, perhaps we don't actually have that many changes that need to happen, and thus NPP is not relevant, but even in that case, I'd like to see a more formal proposal, with at least an analysis of how much code currently available on Hackage would break if we changed `map`s signature. -- Andrew On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Earlier versions of the haskell standard originally named fmap map. It > was only as of haskell 1.4 or so that what was then map got renamed to map > > I think the only technical objection is making sure that theres no > performance regressions wrt applicable fusion opportunities. > > Subject to that, hearty plus one to fmap reclaiming map :) > > Although I would prefer the far more radical (and thus far more > unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. > > I'd vote for that too. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Fri Mar 13 17:33:23 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 13 Mar 2015 18:33:23 +0100 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: Well put Andew! Put me as a -1 as well. On Fri, Mar 13, 2015 at 6:29 PM, Andrew Gibiansky < andrew.gibiansky at gmail.com> wrote: > While I love the idea of gradually "cleaning up" the Prelude, I have a few > problems with this proposal. > > 1. This will break documentation *everywhere*. This will make the > majority of beginner tutorials flag out *wrong*. This is already happening > a bit with type signatures due to BBP, but my intuition tells me that `map` > and `fmap` are even more commonly used in tutorials, and will break even > more. > > 2. If we're willing to make changes to `map`, are there other things that > we want to generalize or clean up? Rather than a dozen small email threads > about "add this function" or "generalize this", perhaps we could instead > take a good hard look at the Prelude, and decide on a long-scale migration > plan. What do we want in the long run? How do we accomplish it with least > breakage? What sort of tooling can we develop -- language extensions, > Haskell preprocessors, etc -- that could make a migration to a cleaner > prelude as easy as possible? Overall, I am a huge fan of striving towards a > more beautiful Prelude, but I want it done in a principled way. I fear that > if these sorts of threads are the way it happens, we will hear from a very > select few among the Haskell community, and the spectacle of BBP may repeat > itself. > > 3. This would break a lot of code, I think. My intuition tells me that > using `map` instead of `fmap` is often used to specify types -- that is, > many places will be ambiguous if we generalize map. > > So, fairly strong -1 from me on this specific proposal in its current form. > > However, if we want to continue cleaning up Prelude in a more principled > way, I would strongly support that. How about something like this? > > 1. Gather a group of people interested in designing a proposal to clean up > the Haskell prelude -- NPP, the New Prelude Proposal. > 2. Detail an exhaustive list of changes we *could* want to make to the > current Prelude. > 3. Decide which of these changes are feasible to make in the near future > (next five years). > 4. Decide how we could make each of the changes, specifically figuring out > how much code would break, how the change could be made to avoid breakage, > and so on. > 5. Organize the implementation of tools and extensions necessary to > minimize breakage, and slowly work towards fixing our Prelude. > > That said, perhaps we don't actually have that many changes that need to > happen, and thus NPP is not relevant, but even in that case, I'd like to > see a more formal proposal, with at least an analysis of how much code > currently available on Hackage would break if we changed `map`s signature. > > -- Andrew > > On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Earlier versions of the haskell standard originally named fmap map. It >> was only as of haskell 1.4 or so that what was then map got renamed to map >> >> I think the only technical objection is making sure that theres no >> performance regressions wrt applicable fusion opportunities. >> >> Subject to that, hearty plus one to fmap reclaiming map :) >> > Although I would prefer the far more radical (and thus far more >> unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. >> >> I'd vote for that too. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Fri Mar 13 20:13:49 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 13 Mar 2015 20:13:49 +0000 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: I imagine there's a lot of code that's relying on the old map for inference, and changing this would make types ambiguous. That is a huge penalty to pay for what is mostly a nice-to-have. If people care this strongly about being able to use `map` in their own code, then I think the only solution is to use a custom Prelude. -1. On Fri, Mar 13, 2015 at 5:33 PM, Adam Bergmark wrote: > Well put Andew! Put me as a -1 as well. > > > On Fri, Mar 13, 2015 at 6:29 PM, Andrew Gibiansky < > andrew.gibiansky at gmail.com> wrote: > >> While I love the idea of gradually "cleaning up" the Prelude, I have a >> few problems with this proposal. >> >> 1. This will break documentation *everywhere*. This will make the >> majority of beginner tutorials flag out *wrong*. This is already happening >> a bit with type signatures due to BBP, but my intuition tells me that `map` >> and `fmap` are even more commonly used in tutorials, and will break even >> more. >> >> 2. If we're willing to make changes to `map`, are there other things that >> we want to generalize or clean up? Rather than a dozen small email threads >> about "add this function" or "generalize this", perhaps we could instead >> take a good hard look at the Prelude, and decide on a long-scale migration >> plan. What do we want in the long run? How do we accomplish it with least >> breakage? What sort of tooling can we develop -- language extensions, >> Haskell preprocessors, etc -- that could make a migration to a cleaner >> prelude as easy as possible? Overall, I am a huge fan of striving towards a >> more beautiful Prelude, but I want it done in a principled way. I fear that >> if these sorts of threads are the way it happens, we will hear from a very >> select few among the Haskell community, and the spectacle of BBP may repeat >> itself. >> >> 3. This would break a lot of code, I think. My intuition tells me that >> using `map` instead of `fmap` is often used to specify types -- that is, >> many places will be ambiguous if we generalize map. >> >> So, fairly strong -1 from me on this specific proposal in its current >> form. >> >> However, if we want to continue cleaning up Prelude in a more principled >> way, I would strongly support that. How about something like this? >> >> 1. Gather a group of people interested in designing a proposal to clean >> up the Haskell prelude -- NPP, the New Prelude Proposal. >> 2. Detail an exhaustive list of changes we *could* want to make to the >> current Prelude. >> 3. Decide which of these changes are feasible to make in the near future >> (next five years). >> 4. Decide how we could make each of the changes, specifically figuring >> out how much code would break, how the change could be made to avoid >> breakage, and so on. >> 5. Organize the implementation of tools and extensions necessary to >> minimize breakage, and slowly work towards fixing our Prelude. >> >> That said, perhaps we don't actually have that many changes that need to >> happen, and thus NPP is not relevant, but even in that case, I'd like to >> see a more formal proposal, with at least an analysis of how much code >> currently available on Hackage would break if we changed `map`s signature. >> >> -- Andrew >> >> On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >>> Earlier versions of the haskell standard originally named fmap map. It >>> was only as of haskell 1.4 or so that what was then map got renamed to map >>> >>> I think the only technical objection is making sure that theres no >>> performance regressions wrt applicable fusion opportunities. >>> >>> Subject to that, hearty plus one to fmap reclaiming map :) >>> > Although I would prefer the far more radical (and thus far more >>> unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. >>> >>> I'd vote for that too. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Fri Mar 13 22:40:24 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Fri, 13 Mar 2015 15:40:24 -0700 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: Agreed, -1 from me. Painting the bike shed isn't a very good use of everyone's brainpower, and doing so in an incremental fashion will just drag out the pain of Prelude / base redesign. Lets either rip off the band aid in one go, or settle with modern Haskell eschewing much of the Prelude. Personally, things like this and BBP make me wish there wasn't a Prelude in the first place. At least it's helpful for improving Haskell's scores in code golf :) -Michael On Fri, Mar 13, 2015 at 10:29 AM, Andrew Gibiansky wrote: > While I love the idea of gradually "cleaning up" the Prelude, I have a few > problems with this proposal. > > 1. This will break documentation *everywhere*. This will make the majority > of beginner tutorials flag out *wrong*. This is already happening a bit with > type signatures due to BBP, but my intuition tells me that `map` and `fmap` > are even more commonly used in tutorials, and will break even more. > > 2. If we're willing to make changes to `map`, are there other things that we > want to generalize or clean up? Rather than a dozen small email threads > about "add this function" or "generalize this", perhaps we could instead > take a good hard look at the Prelude, and decide on a long-scale migration > plan. What do we want in the long run? How do we accomplish it with least > breakage? What sort of tooling can we develop -- language extensions, > Haskell preprocessors, etc -- that could make a migration to a cleaner > prelude as easy as possible? Overall, I am a huge fan of striving towards a > more beautiful Prelude, but I want it done in a principled way. I fear that > if these sorts of threads are the way it happens, we will hear from a very > select few among the Haskell community, and the spectacle of BBP may repeat > itself. > > 3. This would break a lot of code, I think. My intuition tells me that using > `map` instead of `fmap` is often used to specify types -- that is, many > places will be ambiguous if we generalize map. > > So, fairly strong -1 from me on this specific proposal in its current form. > > However, if we want to continue cleaning up Prelude in a more principled > way, I would strongly support that. How about something like this? > > 1. Gather a group of people interested in designing a proposal to clean up > the Haskell prelude -- NPP, the New Prelude Proposal. > 2. Detail an exhaustive list of changes we *could* want to make to the > current Prelude. > 3. Decide which of these changes are feasible to make in the near future > (next five years). > 4. Decide how we could make each of the changes, specifically figuring out > how much code would break, how the change could be made to avoid breakage, > and so on. > 5. Organize the implementation of tools and extensions necessary to minimize > breakage, and slowly work towards fixing our Prelude. > > That said, perhaps we don't actually have that many changes that need to > happen, and thus NPP is not relevant, but even in that case, I'd like to see > a more formal proposal, with at least an analysis of how much code currently > available on Hackage would break if we changed `map`s signature. > > -- Andrew > > On Fri, Mar 13, 2015 at 8:06 AM, Carter Schonwald > wrote: >> >> Earlier versions of the haskell standard originally named fmap map. It >> was only as of haskell 1.4 or so that what was then map got renamed to map >> >> I think the only technical objection is making sure that theres no >> performance regressions wrt applicable fusion opportunities. >> >> Subject to that, hearty plus one to fmap reclaiming map :) >> >> > Although I would prefer the far more radical (and thus far more >> unlikely to ever happen) approach of actually renaming 'fmap' to 'map'. >> >> I'd vote for that too. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From lemming at henning-thielemann.de Fri Mar 13 23:03:34 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 14 Mar 2015 00:03:34 +0100 (CET) Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: On Fri, 13 Mar 2015, Michael Sloan wrote: > Agreed, -1 from me. Painting the bike shed isn't a very good use of > everyone's brainpower, and doing so in an incremental fashion will > just drag out the pain of Prelude / base redesign. Lets either rip > off the band aid in one go, or settle with modern Haskell eschewing > much of the Prelude. > > Personally, things like this and BBP make me wish there wasn't a > Prelude in the first place. I would prefer to stop patching Prelude and instead promote: https://ghc.haskell.org/trac/ghc/wiki/SplitBase From ivan.miljenovic at gmail.com Fri Mar 13 23:10:56 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sat, 14 Mar 2015 10:10:56 +1100 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: On 14 March 2015 at 10:03, Henning Thielemann wrote: > > On Fri, 13 Mar 2015, Michael Sloan wrote: > >> Agreed, -1 from me. Painting the bike shed isn't a very good use of >> everyone's brainpower, and doing so in an incremental fashion will >> just drag out the pain of Prelude / base redesign. Lets either rip >> off the band aid in one go, or settle with modern Haskell eschewing >> much of the Prelude. >> >> Personally, things like this and BBP make me wish there wasn't a >> Prelude in the first place. > > > I would prefer to stop patching Prelude and instead promote: > https://ghc.haskell.org/trac/ghc/wiki/SplitBase +1 to this (And -1 to the actual proposal for all the reasons stated.) -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From voldermort at hotmail.com Sun Mar 15 15:05:21 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 15 Mar 2015 08:05:21 -0700 (MST) Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> Message-ID: <1426431921434-5767023.post@n5.nabble.com> +1 for generalising map. People who think that it will break lots of code should compile some popular packages and see for themselves. As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement. -- View this message in context: http://haskell.1045720.n5.nabble.com/Generalizing-map-tp5766936p5767023.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From jwlato at gmail.com Sun Mar 15 15:24:41 2015 From: jwlato at gmail.com (John Lato) Date: Sun, 15 Mar 2015 15:24:41 +0000 Subject: Generalizing map? References: <5502C154.8050009@plaimi.net> <1426431921434-5767023.post@n5.nabble.com> Message-ID: -1. On 08:05, Sun, Mar 15, 2015 Jeremy wrote: > +1 for generalising map. > > People who think that it will break lots of code should compile some > popular > packages and see for themselves. As for a better/no prelude, this has been > talked about for years, but a wholesale replacement of the prelude hasn't > happened yet and probably won't. Waiting for something that won't happen is > no reason to block gradual improvement. > > > > -- > View this message in context: http://haskell.1045720.n5. > nabble.com/Generalizing-map-tp5766936p5767023.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Mar 15 16:45:59 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 15 Mar 2015 12:45:59 -0400 Subject: Proposal: add chunksOf to Data.Sequence Message-ID: Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements each. The internal "splitMap" function Data.Sequence uses to implement zipWith supports a simple and efficient implementation of chunksOf. All in favor, say "aye". Also, I'm still waiting for a response (any response) to my "cycleN" proposal. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Sun Mar 15 17:56:16 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Sun, 15 Mar 2015 10:56:16 -0700 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> <1426431921434-5767023.post@n5.nabble.com> Message-ID: > As for a better/no prelude, this has been talked about for years, but a wholesale replacement of the prelude hasn't happened yet and probably won't. Waiting for something that won't happen is no reason to block gradual improvement. Note that I am not arguing for waiting for a wholesale replacement! I am all in favor of gradual improvement -- in fact, I think that's the only way to go about improving the prelude. But that gradual improvement can be *targeted*. We can have a plan, instead of having dozens of tiny proposals about adding this function or generalizing another function or deprecating a function. That is what I was arguing for. -- Andrew On Sun, Mar 15, 2015 at 8:24 AM, John Lato wrote: > -1. > > On 08:05, Sun, Mar 15, 2015 Jeremy wrote: > >> +1 for generalising map. >> >> People who think that it will break lots of code should compile some >> popular >> packages and see for themselves. As for a better/no prelude, this has been >> talked about for years, but a wholesale replacement of the prelude hasn't >> happened yet and probably won't. Waiting for something that won't happen >> is >> no reason to block gradual improvement. >> >> >> >> -- >> View this message in context: http://haskell.1045720.n5. >> nabble.com/Generalizing-map-tp5766936p5767023.html >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbouscal at gmail.com Sun Mar 15 18:25:13 2015 From: nbouscal at gmail.com (Nathan Bouscal) Date: Sun, 15 Mar 2015 11:25:13 -0700 Subject: Generalizing map? In-Reply-To: References: <5502C154.8050009@plaimi.net> <1426431921434-5767023.post@n5.nabble.com> Message-ID: I strongly agree with Andrew's suggestion of figuring out exactly what we want the Prelude to be and then moving toward that goal. A principled, intentional approach to this would be really wonderful. That said, I don't agree with holding off on concrete small changes in the meantime, because my pessimistic side doesn't actually expect that principled approach to ever come to fruition. Rejecting a proposal like this current one in favor of a more thorough, principled approach seems to me like allowing the perfect to be the enemy of the good. I would rather have a team working on the better solution, but allow the merely good solutions to continue happening in parallel. I'm skeptical about code breakage, and think we should simply test it and find out. >From my (very limited) experience teaching beginners, I expect this change to improve things, not make them worse. I'm glad to see that Chris's much greater experience in this area seems to corroborate this. That leaves me at +1 on this for now, conditional on testing to be sure that it wouldn't cause significant code breakage or problems with fusion. (I'm also a quixotic +1 on going all the way and renaming fmap to map, but can't imagine that actually happening any time soon.) On Sun, Mar 15, 2015 at 10:56 AM, Andrew Gibiansky < andrew.gibiansky at gmail.com> wrote: > > As for a better/no prelude, this has been > talked about for years, but a wholesale replacement of the prelude hasn't > happened yet and probably won't. Waiting for something that won't happen is > no reason to block gradual improvement. > > Note that I am not arguing for waiting for a wholesale replacement! I am > all in favor of gradual improvement -- in fact, I think that's the only way > to go about improving the prelude. > > But that gradual improvement can be *targeted*. We can have a plan, > instead of having dozens of tiny proposals about adding this function or > generalizing another function or deprecating a function. That is what I was > arguing for. > > -- Andrew > > On Sun, Mar 15, 2015 at 8:24 AM, John Lato wrote: > >> -1. >> >> On 08:05, Sun, Mar 15, 2015 Jeremy wrote: >> >>> +1 for generalising map. >>> >>> People who think that it will break lots of code should compile some >>> popular >>> packages and see for themselves. As for a better/no prelude, this has >>> been >>> talked about for years, but a wholesale replacement of the prelude hasn't >>> happened yet and probably won't. Waiting for something that won't happen >>> is >>> no reason to block gradual improvement. >>> >>> >>> >>> -- >>> View this message in context: http://haskell.1045720.n5. >>> nabble.com/Generalizing-map-tp5766936p5767023.html >>> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Mon Mar 16 19:07:22 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Mon, 16 Mar 2015 14:07:22 -0500 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ Message-ID: <20150316190722.GA4833@mintha> Analogs of monadic functions, which likely ought to be in base as part of AMP. I send no patch yet, for I not know which way to do the Data.Traversable <-> Control.Applicative cyclic import. -- | 'filterA' generalizes the list-based 'filter' function. {-# INLINE filterA #-} filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure []) where bool True x = const x bool False _ = id -- | 'mapAndUnzipA' maps its first argument over a list, returning the result as a pair of lists. {-# INLINE mapAndUnzipA #-} mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) mapAndUnzipA f xs = unzip <$> traverse f xs -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. {-# INLINE zipWithA #-} zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] zipWithA f x y = sequenceA (zipWith f x y) -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final result. {-# INLINE zipWithA_ #-} zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () zipWithA_ f x y = sequenceA_ (zipWith f x y) -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. {-# INLINEABLE replicateA #-} {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} replicateA :: (Applicative p) => Int -> p a -> p [a] replicateA n x = sequenceA (replicate n x) -- | 'replicateA_' is like 'replicateA', but discards the result. {-# INLINEABLE replicateA_ #-} {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} replicateA_ :: (Applicative p) => Int -> p a -> p () replicateA_ n x = sequenceA_ (replicate n x) From ekmett at gmail.com Mon Mar 16 19:34:08 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 16 Mar 2015 15:34:08 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: <20150316190722.GA4833@mintha> References: <20150316190722.GA4833@mintha> Message-ID: We've been simply generalizing the types of existing combinators (and leaving them in their existing homes) rather than taking an army of new names and leaving a ghetto of old, less useful combinators that we'd have to clean up later or leave as landmines to trip up newcomers to the language. I have no objection to generalizing the types of these combinators, however. -Edward On Mon, Mar 16, 2015 at 3:07 PM, M Farkas-Dyck wrote: > Analogs of monadic functions, which likely ought to be in base as part of > AMP. > > I send no patch yet, for I not know which way to do the Data.Traversable > <-> Control.Applicative cyclic import. > > -- | 'filterA' generalizes the list-based 'filter' function. > {-# INLINE filterA #-} > filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] > filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure > []) > where > bool True x = const x > bool False _ = id > > -- | 'mapAndUnzipA' maps its first argument over a list, returning the > result as a pair of lists. > {-# INLINE mapAndUnzipA #-} > mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) > mapAndUnzipA f xs = unzip <$> traverse f xs > > -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. > {-# INLINE zipWithA #-} > zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] > zipWithA f x y = sequenceA (zipWith f x y) > > -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final > result. > {-# INLINE zipWithA_ #-} > zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () > zipWithA_ f x y = sequenceA_ (zipWith f x y) > > -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. > {-# INLINEABLE replicateA #-} > {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} > {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} > replicateA :: (Applicative p) => Int -> p a -> p [a] > replicateA n x = sequenceA (replicate n x) > > -- | 'replicateA_' is like 'replicateA', but discards the result. > {-# INLINEABLE replicateA_ #-} > {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} > {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} > replicateA_ :: (Applicative p) => Int -> p a -> p () > replicateA_ n x = sequenceA_ (replicate n x) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 16 22:29:10 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 16 Mar 2015 18:29:10 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: should filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] perhaps be filterA :: (Applicative p) => (a -> p (Maybe be)) -> [a] -> p [b] ? On Mon, Mar 16, 2015 at 3:34 PM, Edward Kmett wrote: > We've been simply generalizing the types of existing combinators (and > leaving them in their existing homes) rather than taking an army of new > names and leaving a ghetto of old, less useful combinators that we'd have > to clean up later or leave as landmines to trip up newcomers to the > language. > > I have no objection to generalizing the types of these combinators, > however. > > -Edward > > On Mon, Mar 16, 2015 at 3:07 PM, M Farkas-Dyck > wrote: > >> Analogs of monadic functions, which likely ought to be in base as part of >> AMP. >> >> I send no patch yet, for I not know which way to do the Data.Traversable >> <-> Control.Applicative cyclic import. >> >> -- | 'filterA' generalizes the list-based 'filter' function. >> {-# INLINE filterA #-} >> filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] >> filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure >> []) >> where >> bool True x = const x >> bool False _ = id >> >> -- | 'mapAndUnzipA' maps its first argument over a list, returning the >> result as a pair of lists. >> {-# INLINE mapAndUnzipA #-} >> mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) >> mapAndUnzipA f xs = unzip <$> traverse f xs >> >> -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. >> {-# INLINE zipWithA #-} >> zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] >> zipWithA f x y = sequenceA (zipWith f x y) >> >> -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final >> result. >> {-# INLINE zipWithA_ #-} >> zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () >> zipWithA_ f x y = sequenceA_ (zipWith f x y) >> >> -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. >> {-# INLINEABLE replicateA #-} >> {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} >> {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} >> replicateA :: (Applicative p) => Int -> p a -> p [a] >> replicateA n x = sequenceA (replicate n x) >> >> -- | 'replicateA_' is like 'replicateA', but discards the result. >> {-# INLINEABLE replicateA_ #-} >> {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} >> {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} >> replicateA_ :: (Applicative p) => Int -> p a -> p () >> replicateA_ n x = sequenceA_ (replicate n x) >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 17 00:43:03 2015 From: david.feuer at gmail.com (David Feuer) Date: Mon, 16 Mar 2015 20:43:03 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: I like your idea, but not your proposed name. I think the Bool/Maybe matter should not be determined by whether it's filterA or filterM. Generalize filterM and give your version a different name. I also have a minor concern about your version. When it doesn't work magic to improve `fmap (fmap f) . filterM g`, and when there isn't enough inlining, those Just constructors could increase allocation. should filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] perhaps be filterA :: (Applicative p) => (a -> p (Maybe be)) -> [a] -> p [b] ? On Mon, Mar 16, 2015 at 3:34 PM, Edward Kmett wrote: > We've been simply generalizing the types of existing combinators (and > leaving them in their existing homes) rather than taking an army of new > names and leaving a ghetto of old, less useful combinators that we'd have > to clean up later or leave as landmines to trip up newcomers to the > language. > > I have no objection to generalizing the types of these combinators, > however. > > -Edward > > On Mon, Mar 16, 2015 at 3:07 PM, M Farkas-Dyck > wrote: > >> Analogs of monadic functions, which likely ought to be in base as part of >> AMP. >> >> I send no patch yet, for I not know which way to do the Data.Traversable >> <-> Control.Applicative cyclic import. >> >> -- | 'filterA' generalizes the list-based 'filter' function. >> {-# INLINE filterA #-} >> filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] >> filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure >> []) >> where >> bool True x = const x >> bool False _ = id >> >> -- | 'mapAndUnzipA' maps its first argument over a list, returning the >> result as a pair of lists. >> {-# INLINE mapAndUnzipA #-} >> mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) >> mapAndUnzipA f xs = unzip <$> traverse f xs >> >> -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. >> {-# INLINE zipWithA #-} >> zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] >> zipWithA f x y = sequenceA (zipWith f x y) >> >> -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final >> result. >> {-# INLINE zipWithA_ #-} >> zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () >> zipWithA_ f x y = sequenceA_ (zipWith f x y) >> >> -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. >> {-# INLINEABLE replicateA #-} >> {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} >> {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} >> replicateA :: (Applicative p) => Int -> p a -> p [a] >> replicateA n x = sequenceA (replicate n x) >> >> -- | 'replicateA_' is like 'replicateA', but discards the result. >> {-# INLINEABLE replicateA_ #-} >> {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} >> {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} >> replicateA_ :: (Applicative p) => Int -> p a -> p () >> replicateA_ n x = sequenceA_ (replicate n x) >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Tue Mar 17 02:59:34 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Tue, 17 Mar 2015 11:59:34 +0900 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: <20150316190722.GA4833@mintha> References: <20150316190722.GA4833@mintha> Message-ID: +1 I feel the awkwardness of the current combinators at times. 2015-03-17 4:07 GMT+09:00 M Farkas-Dyck : > Analogs of monadic functions, which likely ought to be in base as part of > AMP. > > I send no patch yet, for I not know which way to do the Data.Traversable > <-> Control.Applicative cyclic import. > > -- | 'filterA' generalizes the list-based 'filter' function. > {-# INLINE filterA #-} > filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] > filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) (pure > []) > where > bool True x = const x > bool False _ = id > > -- | 'mapAndUnzipA' maps its first argument over a list, returning the > result as a pair of lists. > {-# INLINE mapAndUnzipA #-} > mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) > mapAndUnzipA f xs = unzip <$> traverse f xs > > -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. > {-# INLINE zipWithA #-} > zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] > zipWithA f x y = sequenceA (zipWith f x y) > > -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final > result. > {-# INLINE zipWithA_ #-} > zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () > zipWithA_ f x y = sequenceA_ (zipWith f x y) > > -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. > {-# INLINEABLE replicateA #-} > {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} > {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} > replicateA :: (Applicative p) => Int -> p a -> p [a] > replicateA n x = sequenceA (replicate n x) > > -- | 'replicateA_' is like 'replicateA', but discards the result. > {-# INLINEABLE replicateA_ #-} > {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} > {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} > replicateA_ :: (Applicative p) => Int -> p a -> p () > replicateA_ n x = sequenceA_ (replicate n x) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 17 03:36:57 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 16 Mar 2015 23:36:57 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: Usually that second op is given a different name. e.g. filterMapM or something. On Mon, Mar 16, 2015 at 6:29 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > should filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] > perhaps be filterA :: (Applicative p) => (a -> p (Maybe be)) -> [a] -> p > [b] > ? > > On Mon, Mar 16, 2015 at 3:34 PM, Edward Kmett wrote: > >> We've been simply generalizing the types of existing combinators (and >> leaving them in their existing homes) rather than taking an army of new >> names and leaving a ghetto of old, less useful combinators that we'd have >> to clean up later or leave as landmines to trip up newcomers to the >> language. >> >> I have no objection to generalizing the types of these combinators, >> however. >> >> -Edward >> >> On Mon, Mar 16, 2015 at 3:07 PM, M Farkas-Dyck >> wrote: >> >>> Analogs of monadic functions, which likely ought to be in base as part >>> of AMP. >>> >>> I send no patch yet, for I not know which way to do the Data.Traversable >>> <-> Control.Applicative cyclic import. >>> >>> -- | 'filterA' generalizes the list-based 'filter' function. >>> {-# INLINE filterA #-} >>> filterA :: (Applicative p) => (a -> p Bool) -> [a] -> p [a] >>> filterA p = foldr (\ x -> liftA2 (\ flg -> bool flg (x:) id) (p x)) >>> (pure []) >>> where >>> bool True x = const x >>> bool False _ = id >>> >>> -- | 'mapAndUnzipA' maps its first argument over a list, returning the >>> result as a pair of lists. >>> {-# INLINE mapAndUnzipA #-} >>> mapAndUnzipA :: (Applicative p) => (a -> p (b, c)) -> [a] -> p ([b], [c]) >>> mapAndUnzipA f xs = unzip <$> traverse f xs >>> >>> -- | 'zipWithA' generalizes 'zipWith' to arbitrary applicative functors. >>> {-# INLINE zipWithA #-} >>> zipWithA :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p [c] >>> zipWithA f x y = sequenceA (zipWith f x y) >>> >>> -- | 'zipWithA_' is the extension of 'zipWithA' which ignores the final >>> result. >>> {-# INLINE zipWithA_ #-} >>> zipWithA_ :: (Applicative p) => (a -> b -> p c) -> [a] -> [b] -> p () >>> zipWithA_ f x y = sequenceA_ (zipWith f x y) >>> >>> -- | @'replicateA' n x@ does @x@ @n@ times, gathering the results. >>> {-# INLINEABLE replicateA #-} >>> {-# SPECIALIZE replicateA :: Int -> IO a -> IO [a] #-} >>> {-# SPECIALIZE replicateA :: Int -> Maybe a -> Maybe [a] #-} >>> replicateA :: (Applicative p) => Int -> p a -> p [a] >>> replicateA n x = sequenceA (replicate n x) >>> >>> -- | 'replicateA_' is like 'replicateA', but discards the result. >>> {-# INLINEABLE replicateA_ #-} >>> {-# SPECIALIZE replicateA_ :: Int -> IO a -> IO () #-} >>> {-# SPECIALIZE replicateA_ :: Int -> Maybe a -> Maybe () #-} >>> replicateA_ :: (Applicative p) => Int -> p a -> p () >>> replicateA_ n x = sequenceA_ (replicate n x) >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Mar 17 08:09:32 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 17 Mar 2015 09:09:32 +0100 (CET) Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: On Mon, 16 Mar 2015, Edward Kmett wrote: > Usually that second op is given a different name. e.g. filterMapM or something. If it is a mapMaybe, why not mapMaybeA or mapMaybeM? From ekmett at gmail.com Tue Mar 17 08:50:46 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 17 Mar 2015 04:50:46 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: That sounds about right. Data.Maybe is out of the way enough few would object if we extending it to include that function. I'm pretty much +/- 0 on it. -Edward On Tue, Mar 17, 2015 at 4:09 AM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 16 Mar 2015, Edward Kmett wrote: > > Usually that second op is given a different name. e.g. filterMapM or >> something. >> > > If it is a mapMaybe, why not mapMaybeA or mapMaybeM? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Tue Mar 17 18:21:34 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 17 Mar 2015 14:21:34 -0400 Subject: zipWithA, zipWithA_, mapAndUnzipA, filterA, replicateA, replicateA_ In-Reply-To: References: <20150316190722.GA4833@mintha> Message-ID: <911CB4F4-3E86-4129-A2A8-9ED8A54C6202@gmail.com> Yes, that's a better name imo Tom El Mar 17, 2015, a las 4:09, Henning Thielemann escribi?: > > On Mon, 16 Mar 2015, Edward Kmett wrote: > >> Usually that second op is given a different name. e.g. filterMapM or something. > > If it is a mapMaybe, why not mapMaybeA or mapMaybeM? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From petr.mvd at gmail.com Tue Mar 17 20:57:29 2015 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Tue, 17 Mar 2015 20:57:29 +0000 Subject: Expand the Data.Set API In-Reply-To: References: Message-ID: What would be use-cases for (2)? As Joachim pointed out, for any reasonable data type inserting an equal element should have no difference. For (3) I'd be in favor of alterF :: (Functor f, Ord a) => a -> (Bool -> f Bool) -> Set a -> f (Set a) (with any reasonable name) which'd allow to examine a set and possibly modify it in one traversal. It should be smart enough not to modify the set at all if the output of a given function is the same as its input. And it'd also fit with lens. In particular, query+delete could be then expressed as memberDelete :: (Ord a) => a -> Set a -> (Bool, Set a) memberDelete k = alterF k (flip (,) False) Petr ?t 5. 3. 2015 v 23:59 odes?latel David Feuer napsal: > There are a few rather conspicuously missing features: > > 1. A way to take the intersection of a list of sets. This shouldn't > really be a big deal, and it already exists for unions, but the > intersection version should probably sort the sets by size before > folding, or otherwise try to do something smart. > > 2. A way to insert an element if an == one is not already present > (insert replaces an existing one with a new one). Currently, as far as > I can tell, this can only be done using either > > if e `member` s then s else insert e s > which potentially descends the tree twice for no reason > > or > > s `union` singleton e > > which is documented as being O(|s|+1), although I wouldn't be shocked > if the documentation were too pessimistic in this case. > > 3. A way to delete an element and simultaneously find out whether it > was in the set. > > David Feuer > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 17 22:27:00 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 17 Mar 2015 18:27:00 -0400 Subject: Expand the Data.Set API In-Reply-To: References: Message-ID: On Mar 17, 2015 4:57 PM, "Petr Pudl?k" wrote: > > What would be use-cases for (2)? As Joachim pointed out, for any reasonable data type inserting an equal element should have no difference. I don't feel strongly about it; it was just a thought. > For (3) I'd be in favor of > > alterF :: (Functor f, Ord a) => a -> (Bool -> f Bool) -> Set a -> f (Set a) That seems quite reasonable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Wed Mar 18 01:25:34 2015 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 18 Mar 2015 03:25:34 +0200 Subject: Proposed significant breaking changes to Win32 Message-ID: There are some discussions going on in this issue: https://github.com/haskell/win32/issues/24 with proposals for extensive breaking changes to the Win32 library. Well over 100 functions would be involved. These changes would finally fix many long outstanding defects in the API, some of which make it impossible to use important Win32 functions in the way originally intended. I would generally support these proposals (after having seen that Neil supports them). But does anyone have any estimate of how much breakage it would cause on Hackage, or in the Windows builds of GHC? Thanks, Yitz From elliot.robinson at argiopetech.com Wed Mar 18 04:36:32 2015 From: elliot.robinson at argiopetech.com (Elliot Robinson) Date: Wed, 18 Mar 2015 00:36:32 -0400 Subject: Proposed significant breaking changes to Win32 In-Reply-To: References: Message-ID: <20150318043632.GA929@suwako.argiopetech.com> A quick reverse search [0] shows 74 packages having Win32 as a direct dependency, 3 of which are out of date. The big ones that stand out to me are `directory` (which will be up to Phil and me to fix) and `process` (which is maintained by Michael Snoyman). Both are GHC dependencies, and each has 800+ reverse dependencies, so the release timing there will need to be well managed (possibly to coincide with the next major GHC RC?). This being said, I'm definitely in favor of better Win32 support. If it takes some extra effort to fix long-standing defects, that's the price of doing business. [0] http://packdeps.haskellers.com/reverse/Win32 On 03/18/15, Yitzchak Gale wrote: > There are some discussions going on in this issue: > > https://github.com/haskell/win32/issues/24 > > with proposals for extensive breaking changes > to the Win32 library. Well over 100 functions would > be involved. These changes would finally fix many > long outstanding defects in the API, some of which > make it impossible to use important Win32 functions > in the way originally intended. > > I would generally support these proposals (after having > seen that Neil supports them). But does anyone have > any estimate of how much breakage it would cause on > Hackage, or in the Windows builds of GHC? > > Thanks, > Yitz > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Elliot Robinson GPG Key: 9FEDE59A From cheecheeo at gmail.com Wed Mar 18 21:29:25 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Wed, 18 Mar 2015 14:29:25 -0700 Subject: Proposal: Export cycleN from Data.Sequence In-Reply-To: References: Message-ID: +1, `cycleN` is Data.Sequence's corollary of `cycle` in Data.List On Wed, Mar 11, 2015 at 8:14 AM, David Feuer wrote: > Yesterday I rewrote `*>` for Data.Sequence (again), using an internal > function > > cycleN :: Int -> Seq a -> Seq a > > The name of the function is based on that of Data.Sequence.iterateN. > cycleN takes a sequence and cycles it as many times as requested: > > cycleN 0 $ fromList [1,2] = [] > cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] > > The function is written to maximize sharing in the result sequence and > to minimize construction time. Specifically, cycleN n xs should take > something like O(|xs| + log n) space (of which all but O(log |xs| + > log n) is shared with the structure of xs) and O(log |xs| + log n) > time. > > With current (on GitHub) Data.Sequence exports, the only way to get > this functionality with these time and space bounds is to combine > replicate with *> : > > cycleN n xs = replicate n () *> xs > > This strikes me as a bit unpleasant. > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Thu Mar 19 21:31:34 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Thu, 19 Mar 2015 16:31:34 -0500 Subject: Proposal: parametrize tree stem container type in containers Message-ID: <20150319213133.GA31136@mintha> A few years ago I uploaded the package generic-tree to Hackage (before I knew the customary version scheme, sorry about that) which has trees parametrized over stem container type: data Tree v a = Node a (v (Tree v a)) As this is a functional superset of the containers tree, I think it appropriate to include in containers, which I hereby propose. Ultimately, if this is accepted, I would like to define the list-specialized tree in terms of this. From shachaf at gmail.com Thu Mar 19 22:12:12 2015 From: shachaf at gmail.com (Shachaf Ben-Kiki) Date: Thu, 19 Mar 2015 15:12:12 -0700 Subject: Proposal: parametrize tree stem container type in containers In-Reply-To: <20150319213133.GA31136@mintha> References: <20150319213133.GA31136@mintha> Message-ID: This is the cofree comonad on a functor v. It's available in . Shachaf On Thu, Mar 19, 2015 at 2:31 PM, M Farkas-Dyck wrote: > A few years ago I uploaded the package generic-tree to Hackage (before I knew the customary version scheme, sorry about that) which has trees parametrized over stem container type: > > data Tree v a = Node a (v (Tree v a)) > > As this is a functional superset of the containers tree, I think it appropriate to include in containers, which I hereby propose. > > Ultimately, if this is accepted, I would like to define the list-specialized tree in terms of this. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From mark.lentczner at gmail.com Sat Mar 21 17:54:26 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 21 Mar 2015 10:54:26 -0700 Subject: wither the Platform Message-ID: I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: *1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. *3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 21 22:32:51 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 21 Mar 2015 15:32:51 -0700 Subject: wither the Platform In-Reply-To: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> References: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> Message-ID: Eeek! I really really did mean to make the subject *whither*, not *wither!*? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhoermann at gmail.com Sat Mar 21 23:21:38 2015 From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=) Date: Sun, 22 Mar 2015 00:21:38 +0100 Subject: wither the Platform In-Reply-To: References: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> Message-ID: I can't speak for others but as a regular but enthusiastic Haskell user the platform always (not just since sandboxes) felt outdated and limited to the included packages since the rest of the Haskell ecosystem rapidly moved on after a platform release (or even during its stabilization freeze phase before a release). The platform is quite similar to Linux distributions like Debian stable or RedHat Enterprise Linux in that sense. Running software not in their repositories on one of those is a bit of a pain and not for the beginner too, just as running packages outside the HP can be when you start out with it. The majority of the Haskell power users (library authors, people interested in the language development itself,...) on the other hand run Haskell more like a rolling release Linux distribution, dealing with problems due to cutting edge versions as they arise which means cutting Hackage versions do not build on the HP. On the other hand new versions that do compile very rarely seem to cause major issues, offering little incentive to use older versions for power users outside enterprise support environments. Perhaps Haskell does need some kind of multi-tier system as those Linux distributions use? LTS and Stackage seem to be attempts to do just that. In any case, I do not think the HP is the best environment for the new Haskell user. Perhaps listing the possible types of users and their requirements and limitations would be helpful to decide what, if anything, should replace the HP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun Mar 22 01:01:01 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 22 Mar 2015 02:01:01 +0100 Subject: wither the Platform In-Reply-To: References: Message-ID: <20150322010101.GA20979@x60s.casa> On Sat, Mar 21, 2015 at 10:54:26AM -0700, Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... Thanks for having written this post Mark. > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. I recall trying haskell some years ago, when I was still a Windows user; the platform was /very/ easy to install, and it served me well in my first functional steps (namely, going through Learn You a Haskell). If we compare it with the old Haskell platform [1], the new downloads section [2] looks more complicated. The pages for the various OSes are even more intimidating (I don't use Ubuntu, but my first question would be "What are those commands doing? Why do I need them?"; same could be said for Win/OSX). [1] https://www.haskell.org/platform/ [2] https://www.haskell.org/downloads > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > *1) Abandon the Platform.* GHC is release in source and binary form. Other > package various installers, with more or less things, for various OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. I am not experienced enough to answer this, but whichever action will be taken, let me say: "think of the children!", i.e. an immediately usable, easily installable system for those who would like to try Haskell out. From apfelmus at quantentunnel.de Sun Mar 22 08:47:34 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Sun, 22 Mar 2015 09:47:34 +0100 Subject: wither the Platform In-Reply-To: References: Message-ID: Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > *1) Abandon the Platform.* GHC is release in source and binary form. Other > package various installers, with more or less things, for various OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > Thoughts? Thanks a lot for your hard work on the platform! I myself am an avid user of the platform (OS X), because for me, it's the easiest way to install Haskell on a new machine; I just did so the other day. The only time when the platform seems to be a handicap is when a new version of GHC is being released and I would have to update my packages. Usually, I don't test them with the new version and rely on pull requests instead. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From ndmitchell at gmail.com Sun Mar 22 09:17:54 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun, 22 Mar 2015 09:17:54 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart. Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. I can get up to the platform with one invoke of cabal, and if someone decides to require a new network, it just works. I think the Platform now gives a worse user experience on Windows, so the ideas (or names) probably need migrating around. Thanks, Neil On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus wrote: > Mark Lentczner wrote: >> >> I'm wondering how we are all feeling about the platform these days.... >> >> I notice that in the new Haskell pages, the Platform is definitely not the >> recommended way to go: The main download pages suggests the compiler and >> base libraries as the first option - and the text for the Platform (second >> option) pretty much steers folks away from it. Of the per-OS download >> pages, only the Windows version even mentions it. >> >> Does this mean that we don't want to consider continuing with it? It is a >> lot of community effort to put out a Platform release - we shouldn't do it >> if we don't really want it. >> >> That said, I note that the other ways to "officially get" Haskell look, to >> my eye, very ad hoc. Many of the options involve multiple steps, and >> exactly what one is getting isn't clear. It hardly looks like there is now >> an "official, correct" way to setup Haskell. >> >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. >> >> >> I don't think the status quo for the Platform is now viable - mostly as >> evidenced by waning interest in maintaining it. I offer several ways we >> could proceed: >> >> *1) Abandon the Platform.* GHC is release in source and binary form. Other >> package various installers, with more or less things, for various OSes. >> >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of >> "essential" libs + tools. Keeps a consistent build layout and installation >> mechanism for Haskell. >> >> *3) Re-conceive the Platform.* Take a very minimal install approach, >> coupled with close integration with a curated library set that makes it >> easy to have a rich canonical, stable environment. This was the core idea >> around my "GPS Haskell" thoughts from last September - but there would be >> much to work out in this direction. >> >> Thoughts? > > > Thanks a lot for your hard work on the platform! > > I myself am an avid user of the platform (OS X), because for me, it's the > easiest way to install Haskell on a new machine; I just did so the other > day. > > The only time when the platform seems to be a handicap is when a new version > of GHC is being released and I would have to update my packages. Usually, I > don't test them with the new version and rely on pull requests instead. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From benno.fuenfstueck at gmail.com Sun Mar 22 09:43:15 2015 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sun, 22 Mar 2015 09:43:15 +0000 Subject: wither the Platform References: Message-ID: I'd like the haskell platform to include all of LTS haskell. That includes a very broad set of packages so you don't need to install many other packages even as an advanced user. Maybe there could also be a nightly release which includes stackage instead? It would save a lot of time even for experienced users, since they get stackage precompiled. However, such a distribution should be designed such that cabal install just works, so it should probably be based on winghc on Windows. The only problem I can see with this is the size of such a package, not sure if it would be acceptable? Neil Mitchell schrieb am So., 22. M?r. 2015 10:18: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. > > Nowadays I use https://github.com/fpco/minghc which can actually > install network, and I've had zero problems. I can get up to the > platform with one invoke of cabal, and if someone decides to require a > new network, it just works. > > I think the Platform now gives a worse user experience on Windows, so > the ideas (or names) probably need migrating around. > > Thanks, Neil > > > On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus > wrote: > > Mark Lentczner wrote: > >> > >> I'm wondering how we are all feeling about the platform these days.... > >> > >> I notice that in the new Haskell pages, the Platform is definitely not > the > >> recommended way to go: The main download pages suggests the compiler and > >> base libraries as the first option - and the text for the Platform > (second > >> option) pretty much steers folks away from it. Of the per-OS download > >> pages, only the Windows version even mentions it. > >> > >> Does this mean that we don't want to consider continuing with it? It is > a > >> lot of community effort to put out a Platform release - we shouldn't do > it > >> if we don't really want it. > >> > >> That said, I note that the other ways to "officially get" Haskell look, > to > >> my eye, very ad hoc. Many of the options involve multiple steps, and > >> exactly what one is getting isn't clear. It hardly looks like there is > now > >> an "official, correct" way to setup Haskell. > >> > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the > landscape > >> for use to reconsider what to do. > >> > >> > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > >> > >> *1) Abandon the Platform.* GHC is release in source and binary form. > Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and > installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core > idea > >> around my "GPS Haskell" thoughts from last September - but there would > be > >> much to work out in this direction. > >> > >> Thoughts? > > > > > > Thanks a lot for your hard work on the platform! > > > > I myself am an avid user of the platform (OS X), because for me, it's the > > easiest way to install Haskell on a new machine; I just did so the other > > day. > > > > The only time when the platform seems to be a handicap is when a new > version > > of GHC is being released and I would have to update my packages. > Usually, I > > don't test them with the new version and rely on pull requests instead. > > > > > > Best regards, > > Heinrich Apfelmus > > > > -- > > http://apfelmus.nfshost.com > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Mar 22 09:52:28 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 22 Mar 2015 10:52:28 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Sat, 21 Mar 2015 10:54:26 -0700") References: Message-ID: <87h9tdpder.fsf@gnu.org> On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: [...] > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. [...] > Thoughts? My biggest complaint about the current HP is that it pollutes the global package database with additional packages which leak into `cabal sandbox`es. This causes `cabal sandbox` to provide quite different sandbox environments for HP environments compared to a non-HP environment without those additional packages pre-installed. Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes? Cheers, hvr From roma at ro-che.info Sun Mar 22 10:00:43 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 22 Mar 2015 12:00:43 +0200 Subject: wither the Platform In-Reply-To: <87h9tdpder.fsf@gnu.org> References: <87h9tdpder.fsf@gnu.org> Message-ID: <550E92CB.2020205@ro-che.info> I also thought about it recently. IIRC ghc can already deal with any number of stacked package dbs; we only need to expose this somehow through cabal. On 22/03/15 11:52, Herbert Valerio Riedel wrote: > On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: > > [...] > >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. > > [...] > >> Thoughts? > > My biggest complaint about the current HP is that it pollutes the global > package database with additional packages which leak into `cabal > sandbox`es. This causes `cabal sandbox` to provide quite different > sandbox environments for HP environments compared to a non-HP > environment without those additional packages pre-installed. > > Currently GHC/Cabal knows about a global package db and a user package > db (the user pkg db is is what gets replaced/shadowed by cabal > sandboxes). Maybe we need a 3rd package db sitting between the global > and the user package db that interacts better with cabal sandboxes? > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From hesselink at gmail.com Sun Mar 22 10:17:21 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 22 Mar 2015 11:17:21 +0100 Subject: wither the Platform In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell wrote: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. Slightly OT: If you ever want to prevent cabal from trying to install a different version of a package (since you know it won't work, or will break things) you can put something like this in your cabal config: constraint: network installed I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network. Erik From hvr at gnu.org Sun Mar 22 10:24:00 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 22 Mar 2015 11:24:00 +0100 Subject: wither the Platform In-Reply-To: (Erik Hesselink's message of "Sun, 22 Mar 2015 11:17:21 +0100") References: Message-ID: <87d241pby7.fsf@gnu.org> On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: [...] > I do this for template-haskell, since it's not possible to reinstall > but cabal would occasionally try it. I can imagine it would work well > to prevent the scenario you describe with network. Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well): https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 Cheers, hvr From hesselink at gmail.com Sun Mar 22 10:48:40 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 22 Mar 2015 11:48:40 +0100 Subject: wither the Platform In-Reply-To: <87d241pby7.fsf@gnu.org> References: <87d241pby7.fsf@gnu.org> Message-ID: On Sun, Mar 22, 2015 at 11:24 AM, Herbert Valerio Riedel wrote: > On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: > > [...] > >> I do this for template-haskell, since it's not possible to reinstall >> but cabal would occasionally try it. I can imagine it would work well >> to prevent the scenario you describe with network. > > Why isn't it possible to reinstall TH (unless you also need to depend on > the `ghc` package)? We even explicitly allowed template-haskell to be > reinstallable again in Cabal as there didn't seem any reason to forbid > it anymore (it's no different than e.g. `bytestring` which is > reinstallable as well): > > https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 This was based on my experiences from some time ago. Looking at it now, I think it was just that the dependencies for template-haskell were too loose, i.e. it allowed different major versions of base. When a new version of GHC was released and I was trying it out, it would always try to install the older version, and this never worked. Now that you fixed these constraints (thanks!) it seems you can reinstall, as long as it's the same (major) version. It still prints this ominous warning even in a sandbox: Warning: The following packages are likely to be broken by the reinstalls: ghc-7.8.3 But everything seems to be fine when passing --force. So I guess I can remove the constraint... Erik From ekmett at gmail.com Sun Mar 22 13:06:07 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 22 Mar 2015 09:06:07 -0400 Subject: wither the Platform In-Reply-To: <87d241pby7.fsf@gnu.org> References: <87d241pby7.fsf@gnu.org> Message-ID: The original reason for the cabal hack that prevented it from trying to reinstall template-haskell is that almost every time someone did this it broke, silently. Then five packages later something would use template haskell, and you'd get completely nonsensical error messages, and someone _else_ would get the bug report. Sure there might have been a scenario in which an expert who is working on ghc may want to reinstall the template-haskell to get a new point release, but TH has never worked across multiple GHC versions, and old versions shipped with very wide bounds. Now, of course, maintainers and the trustees have the ability to retroactively narrow bounds (and you've already done so for template-haskell), so this view is dated. template-haskell should just be reinstallable like everything else now. -Edward On Sun, Mar 22, 2015 at 6:24 AM, Herbert Valerio Riedel wrote: > On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: > > [...] > > > I do this for template-haskell, since it's not possible to reinstall > > but cabal would occasionally try it. I can imagine it would work well > > to prevent the scenario you describe with network. > > Why isn't it possible to reinstall TH (unless you also need to depend on > the `ghc` package)? We even explicitly allowed template-haskell to be > reinstallable again in Cabal as there didn't seem any reason to forbid > it anymore (it's no different than e.g. `bytestring` which is > reinstallable as well): > > > https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 > > Cheers, > hvr > _______________________________________________ > 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 strake888 at gmail.com Sun Mar 22 13:53:48 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 22 Mar 2015 08:53:48 -0500 Subject: wither the Platform In-Reply-To: References: Message-ID: On 21/03/2015, Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... I say leave it to the operating system distributions. From gale at sefer.org Sun Mar 22 14:23:23 2015 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 22 Mar 2015 16:23:23 +0200 Subject: wither the Platform In-Reply-To: References: Message-ID: Mark Lentczner wrote: > 1) Abandon the Platform? > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > 3) Re-conceive the Platform. Take a very minimal install approach, coupled > with close integration with a curated library set that makes it easy to have > a rich canonical, stable environment. This was the core idea around my "GPS > Haskell" thoughts from last September - but there would be much to work out > in this direction. I vote for (3) but in a way that it would *not* be much work. We should definitely do the Platform, but with much *less* work. The most important reason we need the Platform is as a default selection of quality basic libraries. We should not abandon that concept. Curated package sets do not replace that - the Platform is not just packages that build together. Nor do OS packagers. The platform is a community-wide set of basic default packages that are mature, well tested, all work together well, and stable. The second most important role of the Platform is a web site where you can get a clear picture of how to download and install a default Haskell installation for your platform, and a simple view of where we are in the parade of releases. That should also continue. The hardest work of the Platform was its role as a way to bootstrap a Haskell installation. That is what made it so hard for HP to keep up with GHC releases, and what consequently gave people the impression that HP is always old. That work doesn't need to be done as part of the Platform anymore. We should leverage other good work people are doing to create installers, and stop doing it as part of the HP process. The most important part of an HP release should be a cabal package that provides the packages in the platform, at the right versions, with a specification of the recommended GHC version as a pre-requisite. Perhaps we can also provide an HP-branded slick installer for some platforms that does everything in one click, built as a thin wrapper of some existing installer. But that should not delay the official release of an HP version. It's just a nice-to-have extra. Once we pare down the work needed for an HP release, we should release new versions of HP quite often - *more* often than GHC releases, not less often. Another thing we should fix is the (now false) impression that HP gets in the way of installing other packages and versions due to cabal hell. We should make "require-sandbox" the default setting in the cabal config file. I would go further - I would add a cabal feature to create a sandbox automatically unless "--user" or "--global" is specified explicitly. I would make "foo installed" a default constraint (that is easy to override) for all platform packages, which solves virtually all cabal hell problems (assuming you are using a sandbox) and will not keep things old if we release often. Thanks, Yitz From michael at snoyman.com Sun Mar 22 15:59:35 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 22 Mar 2015 15:59:35 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: It should go without saying that the first sentiment we all likely have is gratitude for all the work Mark has put into the platform, as well as all of the other contributors and maintainers the platform has had over the years. It hasn't just been work on producing the platform itself, but also for setting up an expectation in the Haskell world for high quality, reliable libraries. Even if the current incarnation of the platform is in jeopardy, I hope that we continue with that attitude going forward. I spend a lot of time working on Stackage, and obviously there's quite a bit of overlap between Stackage, Haskell Platform, and LTS Haskell. For purposes of this discussion, I think it's important to separate out different features of the platform, and see how we may continue or discontinue each individually: 1. A quality-approved set of libraries. As I see it, the process of coming up with recommended libraries can continue completely independently of any other work. 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. And as we've already discussed in the past regarding GPS, there's definitely room to add *more* to the platform with better build dependency solving. LTS Haskell was specifically an effort to try to advance that aspect of GPS. Putting this together, I think it leads to a new approach for the platform: minimalistic installers, curated package sets (ala LTS), recommended packages (ala the current platform set), and a robust means for installing these (e.g., cabal sandboxes). The Haskell world has advanced since the initial HP work, maybe all that's needed now is upgrading to the newest tooling available. I realize I haven't put down any concrete "next steps" here. I definitely have more ideas than I could put into this (already quite long) email. I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. On Sat, Mar 21, 2015 at 7:54 PM Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > *1) Abandon the Platform.* GHC is release in source and binary form. > Other package various installers, with more or less things, for various > OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > Thoughts? > > ? Mark > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sun Mar 22 17:24:55 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 22 Mar 2015 13:24:55 -0400 Subject: [haskell-infrastructure] wither the Platform Message-ID: Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines. A) Users that sandbox and users that do not. B) Libraries that maintain HP compatibility and libraries that do not. The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes ? platform-installed packages being available in sandboxes and causing trouble. However, the current solution we push to new users is lacking in certain ways. In particular, I really don?t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc. Furthermore, it is _very_ important to have some community process to ?bless? or suggest some set of packages from the zoo of hackage as the ?typical? way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc. Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes. Overall I tend to agree with dons? comments on the reddit thread (http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) and think the key idea is to preserve _both_ the ?one stop installer? aspect of the platform and the ?blessed package set? element, but to decouple them from one another. This leads to the following proposals: 1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place. 2) For generic linux point to both ghc and cabal binaries from the core teams. 3) Continue to pick out and list a compatible, ?blessed? set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains. 4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes. And of these I have one outstanding question ? while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can?t solve that, then the MinGHC approach doesn?t yet provide a strictly better solution. Cheers, Gershom On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale at sefer.org) wrote: > Mark Lentczner wrote: > > 1) Abandon the Platform? > > > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > > "essential" libs + tools. Keeps a consistent build layout and installation > > mechanism for Haskell. > > > > 3) Re-conceive the Platform. Take a very minimal install approach, coupled > > with close integration with a curated library set that makes it easy to have > > a rich canonical, stable environment. This was the core idea around my "GPS > > Haskell" thoughts from last September - but there would be much to work out > > in this direction. > > I vote for (3) but in a way that it would *not* be much work. > We should definitely do the Platform, but with much *less* work. > > The most important reason we need the Platform is as > a default selection of quality basic libraries. We should not abandon > that concept. Curated package sets do not replace that - the > Platform is not just packages that build together. Nor do OS > packagers. The platform is a community-wide set of basic default > packages that are mature, well tested, all work together well, > and stable. > > The second most important role of the Platform is a web site > where you can get a clear picture of how to download and install > a default Haskell installation for your platform, and a simple view > of where we are in the parade of releases. That should also continue. > > The hardest work of the Platform was its role as a way to bootstrap a > Haskell installation. That is what made it so hard for HP to keep up > with GHC releases, and what consequently gave people the impression > that HP is always old. That work doesn't need to be done as part of the > Platform anymore. We should leverage other good work people are > doing to create installers, and stop doing it as part of the HP process. > > The most important part of an HP release should be a cabal package > that provides the packages in the platform, at the right versions, with > a specification of the recommended GHC version as a pre-requisite. > > Perhaps we can also provide an HP-branded slick installer for some > platforms that does everything in one click, built as a thin wrapper of > some existing installer. But that should not delay the official release > of an HP version. It's just a nice-to-have extra. > > Once we pare down the work needed for an HP release, we should > release new versions of HP quite often - *more* often than GHC > releases, not less often. > > Another thing we should fix is the (now false) impression that HP > gets in the way of installing other packages and versions due to > cabal hell. We should make "require-sandbox" the default setting > in the cabal config file. I would go further - I would add a cabal > feature to create a sandbox automatically unless "--user" or > "--global" is specified explicitly. I would make "foo installed" a > default constraint (that is easy to override) for all platform packages, > which solves virtually all cabal hell problems (assuming you are > using a sandbox) and will not keep things old if we release often. > > Thanks, > Yitz > _______________________________________________ > haskell-infrastructure mailing list > haskell-infrastructure at community.galois.com > http://community.galois.com/mailman/listinfo/haskell-infrastructure > From mhoermann at gmail.com Sun Mar 22 17:33:42 2015 From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=) Date: Sun, 22 Mar 2015 18:33:42 +0100 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: Message-ID: The sandboxes vs. non-sandboxed install issues are closely related to the whole issue of not being able to easily update a package once it is installed. Perhaps some effort should be invested in solving that problem instead as it seems to be the core cause for the reinstallations which are so much harder for global packages than for sandboxes. On 22 Mar 2015 18:25, "Gershom B" wrote: > Thanks for kicking this off Mark. Here is what I think happened. We > fragmented along two lines. > > A) Users that sandbox and users that do not. > B) Libraries that maintain HP compatibility and libraries that do not. > > The growth of non HP-compat libs is clearly what has driven the growth in > sandboxing users. That brings us to the current situation where new users > who install the platform then run into the issue hvr describes ? > platform-installed packages being available in sandboxes and causing > trouble. > > However, the current solution we push to new users is lacking in certain > ways. In particular, I really don?t like not providing standard > binary/installers from a _single source_ across all platforms. Instead, we > have installers from three sources, with the minimal windows and mac ones > being from small strikeforces or individuals, but not necessarily a team > where everything is documented so others can step in if someone decides to > go off and surf for the rest of their life in an area with poor wi-fi, etc. > > Furthermore, it is _very_ important to have some community process to > ?bless? or suggest some set of packages from the zoo of hackage as the > ?typical? way to accomplish certain tasks, and I think we have been overly > conservative in adding packages to the platform, probably due to the > problem of pulling in unrelated dependencies, etc. This blessed set serves, > among other things, as a core set of packages to advise distro managers on > the baseline they should package, etc. > > Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it > would be good to provide a way for users to maintain a local db that they > like and trust of a set of baseline libs while making it _easy_ to override > these in individual sandboxes. > > Overall I tend to agree with dons? comments on the reddit thread ( > http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) > and think the key idea is to preserve _both_ the ?one stop installer? > aspect of the platform and the ?blessed package set? element, but to > decouple them from one another. > > This leads to the following proposals: > > 1) Reboot the HP installers for windows and mac as effectively the MinGHC > and GHC For Mac OS X, working with those teams but centralizing the > build/packaging knowledge and provide them all from one place. > 2) For generic linux point to both ghc and cabal binaries from the core > teams. > 3) Continue to pick out and list a compatible, ?blessed? set of libraries > under the platform umbrella, but do not necessarily package them with > installers. Reboot interest in expanding and curating further the list of > libraries across a wider range of application domains. > 4) Improve sandbox tooling so that it is easy to exclude packages from the > main database when building within sandboxes. > > And of these I have one outstanding question ? while MinGHC makes it easy > to install network directly on windows machines, what does it do about the > GL libraries? Or for getting a windows GHC with graphics, does the current > platform build remain a better solution? If we can?t solve that, then the > MinGHC approach doesn?t yet provide a strictly better solution. > > Cheers, > Gershom > > On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale at sefer.org) wrote: > > Mark Lentczner wrote: > > > 1) Abandon the Platform? > > > > > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > > > "essential" libs + tools. Keeps a consistent build layout and > installation > > > mechanism for Haskell. > > > > > > 3) Re-conceive the Platform. Take a very minimal install approach, > coupled > > > with close integration with a curated library set that makes it easy > to have > > > a rich canonical, stable environment. This was the core idea around my > "GPS > > > Haskell" thoughts from last September - but there would be much to > work out > > > in this direction. > > > > I vote for (3) but in a way that it would *not* be much work. > > We should definitely do the Platform, but with much *less* work. > > > > The most important reason we need the Platform is as > > a default selection of quality basic libraries. We should not abandon > > that concept. Curated package sets do not replace that - the > > Platform is not just packages that build together. Nor do OS > > packagers. The platform is a community-wide set of basic default > > packages that are mature, well tested, all work together well, > > and stable. > > > > The second most important role of the Platform is a web site > > where you can get a clear picture of how to download and install > > a default Haskell installation for your platform, and a simple view > > of where we are in the parade of releases. That should also continue. > > > > The hardest work of the Platform was its role as a way to bootstrap a > > Haskell installation. That is what made it so hard for HP to keep up > > with GHC releases, and what consequently gave people the impression > > that HP is always old. That work doesn't need to be done as part of the > > Platform anymore. We should leverage other good work people are > > doing to create installers, and stop doing it as part of the HP process. > > > > The most important part of an HP release should be a cabal package > > that provides the packages in the platform, at the right versions, with > > a specification of the recommended GHC version as a pre-requisite. > > > > Perhaps we can also provide an HP-branded slick installer for some > > platforms that does everything in one click, built as a thin wrapper of > > some existing installer. But that should not delay the official release > > of an HP version. It's just a nice-to-have extra. > > > > Once we pare down the work needed for an HP release, we should > > release new versions of HP quite often - *more* often than GHC > > releases, not less often. > > > > Another thing we should fix is the (now false) impression that HP > > gets in the way of installing other packages and versions due to > > cabal hell. We should make "require-sandbox" the default setting > > in the cabal config file. I would go further - I would add a cabal > > feature to create a sandbox automatically unless "--user" or > > "--global" is specified explicitly. I would make "foo installed" a > > default constraint (that is easy to override) for all platform packages, > > which solves virtually all cabal hell problems (assuming you are > > using a sandbox) and will not keep things old if we release often. > > > > Thanks, > > Yitz > > _______________________________________________ > > haskell-infrastructure mailing list > > haskell-infrastructure at community.galois.com > > http://community.galois.com/mailman/listinfo/haskell-infrastructure > > > > _______________________________________________ > 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 Mon Mar 23 03:01:47 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Mar 2015 23:01:47 -0400 Subject: Fixing Fix Message-ID: There are a good number of different packages that define either newtype Fix f = Fix (f (Fix f)) or something equivalent except for naming. Most of the name variation is in the name of the data constructor and/or record selector. This does not look like an ideal situation to me. Most problematically, the only way to convert one to another is with unsafeCoerce. I think it would be rather nice to choose one canonical place for this definition, and let everyone else use it. Ideally, it would be nice to use some GHC pattern magic and such to paper over the differences between the data constructor names, but I don't know if that's possible or not. David Feuer From mark.lentczner at gmail.com Mon Mar 23 05:44:41 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 22 Mar 2015 22:44:41 -0700 Subject: quick report using GHC 7.10 RC3 Message-ID: I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 08:45:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 08:45:48 +0000 Subject: Cabal and simultaneous installations of the same package Message-ID: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon From michael at snoyman.com Mon Mar 23 08:52:31 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 08:52:31 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones wrote: > Dear Cabal developers > > You'll probably have seen the thread about the Haskell Platform. > > Among other things, this point arose: > > | Another thing we should fix is the (now false) impression that HP gets > in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is > referring to here. > > But some time now GHC has allowed multiple versions of the same package > (compiled against different dependencies) to be installed simultaneously. > So all we need to do is to fix Cabal to allow it too, and thereby kill of a > huge class of cabal-hell problems at one blow. > > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because there > are much bigger problems? Or because there is insufficient effort > available? Or what? > > Unless I'm way off beam, this "multiple installations of the same package" > thing has been a huge pain forever, and the solution is within our grasp. > What's stopping us grasping it? > > Simon > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 09:52:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 09:52:55 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." Reading your blog post [1] it seems that we are addressing different questions: ? My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so. ? You agree that the confusing behaviour you describe can?t happen with Cabal. In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up. ? What you want is for the confusing behaviour to be true of GHCi too. Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way. The point is that I may need to install a bunch of packages to build a program. If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal). But at the moment I can?t do that. That leaves open the following question. Suppose ? I want to install and expose package P and Q ? But alas, P depends on containers 2.9 and Q depends on containers 3.1 Now I?m stuck. But there is a good reason for being stuck, and one that is explicable. Simon From: Michael Snoyman [mailto:michael at snoyman.com] Sent: 23 March 2015 08:53 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones > wrote: Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 23 09:58:29 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 09:58:29 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones wrote: > It's already a huge source of confusion for people using GHCi what they > get messages about "ByteString is not ByteString." > > > > Reading your blog post [1] it seems that we are addressing different > questions: > > ? My proposal is only that the act of **installing** a package > does not break existing installed package, and is not rejected because it > risks doing so. > Thank you for the clarification, I had misread that. On that front: I agree. > ? You agree that the confusing behaviour you describe can?t > happen with Cabal. In any one build, Cabal can ensure that only one > version of each package is used in the build, so such a message could never > show up. > I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing. > ? What you want is for the confusing behaviour to be true of > GHCi too. Well that?s simple enough: ensure that the set of *exposed* > packages (ie the ones you say ?import M? for), is consistent in the same > way. The point is that I may need to install a bunch of packages to build > a program. If I?m using Cabal, none of those newly installed packages need > be exposed; I simply need them there so I can compile my program (using > Cabal). But at the moment I can?t do that. > > > > That leaves open the following question. Suppose > > ? I want to install *and expose* package P and Q > > ? But alas, P depends on containers 2.9 and Q depends on > containers 3.1 > > Now I?m stuck. But there is a good reason for being stuck, and one that is > explicable. > > > If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 10:01:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 10:01:32 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: Like Richard, I was astonished by this. I always thought that the Haskell Platform was the route of choice to install GHC, together with a respectable set of libraries. It?s certainly what I install on a new machine! Let?s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to ?How do I install GHC??. It may be that the HP formula needs re-visiting, but I think it?s very important that we continue to give a very simple (click here) answer to that question. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 21 March 2015 17:54 To: ghc-devs at haskell.org; Haskell Libraries; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com Subject: wither the Platform I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: 1) Abandon the Platform. GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. 2) Slim the Platform. Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. 3) Re-conceive the Platform. Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 10:05:56 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 10:05:56 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Correct, esp the bit that I have emboldened. For the former bullets, perhaps Cabal might ask you want you want to do. That still leaves open questions. What happens if you say ?ghc ?package P ?package Q Foo.hs?? Should GHC complain that you?ve chosen an inconsistent set? Perhaps! (NB if P and Q use containers only internally, and do not expose any types from containers, then arguably it?s ok; but I?d argue for jumping that bridge when we come to it.) Simon From: Michael Snoyman [mailto:michael at snoyman.com] Sent: 23 March 2015 09:58 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones > wrote: It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." Reading your blog post [1] it seems that we are addressing different questions: ? My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so. Thank you for the clarification, I had misread that. On that front: I agree. ? You agree that the confusing behaviour you describe can?t happen with Cabal. In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up. I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing. ? What you want is for the confusing behaviour to be true of GHCi too. Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way. The point is that I may need to install a bunch of packages to build a program. If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal). But at the moment I can?t do that. That leaves open the following question. Suppose ? I want to install and expose package P and Q ? But alas, P depends on containers 2.9 and Q depends on containers 3.1 Now I?m stuck. But there is a good reason for being stuck, and one that is explicable. If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Mar 23 10:20:36 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 23 Mar 2015 11:20:36 +0100 Subject: wither the Platform In-Reply-To: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: >From the downloads page on the GHC homepage: Version 7.8.4 (released December 23rd 2014) Stop! For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. On Mon, Mar 23, 2015 at 11:01 AM, Simon Peyton Jones wrote: > I notice that in the new Haskell pages, the Platform is definitely not > the recommended way to go: > > > > Like Richard, I was astonished by this. I always thought that the Haskell > Platform was *the* route of choice to install GHC, together with a > respectable set of libraries. It?s certainly what I install on a new > machine! > > > > Let?s not forget the large but non-vocal set of ill-informed and/or > would-be users, who want a simple answer to ?How do I install GHC??. It > may be that the HP formula needs re-visiting, but I think it?s very > important that we continue to give a very simple (click here) answer to > that question. > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Mark > Lentczner > *Sent:* 21 March 2015 17:54 > *To:* ghc-devs at haskell.org; Haskell Libraries; > haskell-platform at projects.haskell.org; > haskell-infrastructure at community.galois.com > *Subject:* wither the Platform > > > > I'm wondering how we are all feeling about the platform these days.... > > > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > > > *1) Abandon the Platform.* GHC is release in source and binary form. > Other package various installers, with more or less things, for various > OSes. > > > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > > > Thoughts? > > > > ? Mark > > > > _______________________________________________ > 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 hvr at gnu.org Mon Mar 23 10:47:48 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 23 Mar 2015 11:47:48 +0100 Subject: wither the Platform In-Reply-To: (Thomas Miedema's message of "Mon, 23 Mar 2015 11:20:36 +0100") References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87mw34m1m3.fsf@gnu.org> On 2015-03-23 at 11:20:36 +0100, Thomas Miedema wrote: [...] > For most users, we recommend installing the Haskell Platform > instead of GHC. The current Haskell > Platform release includes a recent GHC release as well as some other tools > (such as cabal), and a larger set of libraries that are known to work > together. Btw, I've always wondered a little bit about the last part, namely "set of libraries that are known to work together"... what is actually meant by that? Does it simply refer to providing a selection of package-versions that form a valid coherent/simultaneous Cabal install plan? Cheers, hvr From mark.lentczner at gmail.com Mon Mar 23 14:01:23 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:01:23 -0700 Subject: wither the Platform In-Reply-To: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones wrote: > I notice that in the new Haskell pages, the Platform is definitely not > the recommended way to go: > > > > Like Richard, I was astonished by this. I always thought that the Haskell > Platform was *the* route of choice to install GHC, together with a > respectable set of libraries. It?s certainly what I install on a new > machine! > I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform. It looks like the Platform deprecated on the Haskell.org site for Linux and OS X in June , and for Windows in Jan . *Infrastructure team:* Was there a discussion and decision to do that somewhere? Let?s not forget the large but non-vocal set of ill-informed and/or > would-be users, who want a simple answer to ?How do I install GHC??. It > may be that the HP formula needs re-visiting, but I think it?s very > important that we continue to give a very simple (click here) answer to > that question. > As evidenced by yourself, and those that spoke up here, there is also a vocal, well-informed set of users who want such a thing as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 14:02:51 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:02:51 -0700 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 3:20 AM, Thomas Miedema wrote: > From the downloads page > on the GHC homepage: > Alas, that warning has never been effective. But it is moot anyway: Start from the shiny Haskell.org page and see where you land! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 14:21:07 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:21:07 -0700 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: A common sentiment I see here is that the Platform always seems out of date. That has always been true, and to a degree by design: It is the stable set, not the wild west. Historically, the first release of a major new GHC was seen as needing a bit of a trial period before we enshrined it in a Platform release. Hence, they lagged. There are also other concerns like stable release schedule (which the Platform has been poor at, but has always been a goal). GHC has made great strides in being much more stable out of the gate. And the Platform has been significantly automated recently. For example, there is already an Alpha of the Platform for 7.10 RC3. But it still takes person-power to run it, test it, and get it out. And there is still the issue of stable release times. If you want latest GHC, and latest libs - then Platform is not the way to go. A solid question is: Where do we want to direct the mass of the community? At head? At latest release? At some older, but now stabilized point? What do we want their experience to be? We will best served if the answer is pretty much right for the bulk of the community: not just newcomers, not just people doing production work, not just hobbiests... all of them. Most other language systems manage to have a single distribution that works for the majority of the community, and most of them are content to have much better stability and support. Python put out 2.7.0 in 2010, and 2.7.9 last Dec. It is still supporting 2.7 line (with source and library compatibility) while it is off releasing 3.3 line. This would be for us like deciding to support and update 7.8, and the pre-FTP Prelude for another four years. Which wouldn't be so bad... ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Mar 23 14:27:32 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 10:27:32 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > I do too...! But follow the new Haskell.org pages like you are a user "just > want to install Haskell"... you'll never end up with the Platform. > > It looks like the Platform deprecated on the Haskell.org site for Linux and > OS X in June > , > and for Windows in Jan > > . > *Infrastructure team:* Was there a discussion and decision to do that > somewhere? > I thought the current language on the page was rather balanced? That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet:?https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!). In any case, here is my problem. I would like us to be in a situation where we can always say ?use the platform? to new users. I don?t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing? shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A ?badge? on hackage for platform-compatible packages would do wonders, I think). So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the ?library curation? element of the platform from the ?installing haskell? element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-) Cheers, Gershom From mark.lentczner at gmail.com Mon Mar 23 14:57:06 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:57:06 -0700 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 7:27 AM, Gershom B wrote: > I thought the current language on the page was rather balanced? > It leads any user away from the Platfrom: - From the homepage - "Downloads" from the top bar - First links are three OS links, click any one.... - The Windows one has one link the Platform at bottom after giving you a different way to install - The OS X only mentions the Platform if you have an older OS - The Linux page doesn't mention the Platform at all. - If you read the paragraph on Platform - it basically says don't use it. Personally, I think multiple options in this regard is a failure. We aught to have one path that works for the vast majority of use cases. The reason is that there are many build and packaging choices in getting from source to installed tool chain, and each of these paths makes them differently... which leads to just tons of incompatibility and confusion. If the community wants minimal installers - fine - I wish we had one way not two or three. The Platform has a very complete and automated build - and installers tested on a wide variety of OS versions - it could easily be adapted to a more minimal approach (as per my GPS proposal a way back) if that's what we want. I'd really like to invite folks creating minimal installers to rally around the large body of work, experience, and code in building the Haskell Platform installers. They could easily fashion minimal builds from it (with the Shake build system this is now like a single .hs file of work...)... then perhaps we could have Platform "minimal" and "full" releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Mon Mar 23 14:58:32 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 23 Mar 2015 15:58:32 +0100 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 23 March 2015 at 15:01, Mark Lentczner wrote: > On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones wrote: > > Like Richard, I was astonished by this. I always thought that the > > Haskell Platform was the route of choice to install GHC, together > > with a respectable set of libraries. It?s certainly what I install > > on a new machine! > > I do too...! But follow the new Haskell.org pages like you are a user > "just want to install Haskell"... you'll never end up with the > Platform. Separate from any opinions about what's best going forward, chiming in on a bit of history for the new homepage, my motivations were: I wanted newbies to come to the site and find a download page *within the Haskell.org site* (not going to another site with a different design) that gives them something current and usable. I added the manual GHC install guide (now gone) because that is the method I was most familiar with. I've never used a HP release. So I surveyed the current crop of handy installers and judged community use of these things from mailing lists, reddit, IRC, etc. I saw enough interactions with newbies that the HP was not being recommended anymore due to its old GHC version and old packages (at the time of making that change on the page, the current HP release was very old), and the problem of the global database and installing new things. I'm not really familiar with the user experience of this, but people don't seem to like it. So the Linux install became recommendations of OS-specific installers (e.g. the Ubuntu and Arch repos are often recommended), and Windows remained HP coupled with the new MinGHC (which I also saw being recommended), and OS X became linked to the GHC for Mac OS X project (again, I saw people were using that), each of which claim superiority for various platform-specific reasons over the HP releases. So that's the decision-making process that went into making the page flow like it is. Someone added this text: > Many now recommend just using a bare compiler combined with sandboxed > dependencies, especially for new users. However, others prefer to > start with the curated blessed set of packages in the Haskell > Platform, which is available for Windows, OS X, and Linux. Which adds choice to users ill-equipped to make choice. I didn't add it (although I understand the motivation behind it). From a web site perspective, I'd prefer the download pages just be on the site. If it's these platform-specific installers, the HP, or some new helpful installer + LTS or whatever, it should be just there under /downloads, /downloads/windows, etc. and there should ideally be one, good, current choice. The current page is a compromise, not the final product. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Mar 23 15:05:28 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 23 Mar 2015 16:05:28 +0100 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones wrote: > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because there > are much bigger problems? Or because there is insufficient effort > available? Or what? I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 23 15:10:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Mar 2015 11:10:19 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <8259E963-9441-4E13-8F9F-E84E024EDE65@cis.upenn.edu> On Mar 23, 2015, at 10:58 AM, Christopher Done wrote: > > Someone added this text: > > > Many now recommend just using a bare compiler combined with sandboxed > > dependencies, especially for new users. However, others prefer to > > start with the curated blessed set of packages in the Haskell > > Platform, which is available for Windows, OS X, and Linux. > > Which adds choice to users ill-equipped to make choice. Your point here is a good one. I have to confess I'm not even sure, exactly, what "combined with sandboxed dependencies" means. (Use a sandbox for every package I wish to install, bypassing `cabal install`? Use a sandbox for every package I write? Use a sandbox to write "Hello, world!"? And what about GHCi?) And I'm not a newcomer to Haskell! This is not welcoming, in my opinion. If the recommended installation mentions sandboxes, it's the wrong recommendation, and we should aim for better. Richard From chrisdone at gmail.com Mon Mar 23 15:11:24 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 23 Mar 2015 16:11:24 +0100 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I suppose ironically the page does a good job of representing community opinion; i.e. there is still debate on this issue. Even though ideally the vision was for the site to be as clear as possible, I saw no uncontentious choice here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 23 15:19:14 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Mar 2015 11:19:14 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Forgive me, all, for asking what many may think a silly question, but I must ask: What's wrong with the platform? One non-answer to this question: - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong. How does its age bite? Is the GHC version too old, meaning that users can't install the packages they want? (Are there an older versions of those packages available that *do* work? If so, does cabal find them?) Or, are the packages that ship with the platform out-of-date, causing installation trouble because of high lower-bounds on other packages? My question here hints at the fact that I'm a bit old-fashioned. I generally don't mind when things are out of date, provided that I don't need the new features. Maybe I'm in the minority here, and that the majority of newcomers to Haskell feel the burning need to have the very latest release of everything. But I, personally, would rather have ease of installation and be able to get moving forward without a headache than to have the new, shiny -- especially if I know how to get the new, shiny later if I should need it. Thanks, Richard From allbery.b at gmail.com Mon Mar 23 15:21:33 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 23 Mar 2015 11:21:33 -0400 Subject: wither the Platform In-Reply-To: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg wrote: > - "It's always out-of-date." This statement, while true, isn't a direct > indication that something is wrong. "Perception is reality". The period when the Platform went without an update for over a year because we were waiting on ghc 6.8.3 did a lot to ruin the Platform's reputation. -- 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 simonpj at microsoft.com Mon Mar 23 15:32:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 15:32:39 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <91d2cf5191134135b65cd6d2ae889422@DB4PR30MB030.064d.mgd.msft.net> I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. I?m pretty confident that GHC has all the things needed, and has done since last summer. It?s Cabal that doesn?t! But as you say, Edward Y can confirm. Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 23 March 2015 15:05 To: Simon Peyton Jones Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org; Edward Yang Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones > wrote: But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 23 15:54:55 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 15:54:55 +0000 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery wrote: > On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg > wrote: > >> - "It's always out-of-date." This statement, while true, isn't a direct >> indication that something is wrong. > > > "Perception is reality". The period when the Platform went without an > update for over a year because we were waiting on ghc 6.8.3 did a lot to > ruin the Platform's reputation. > > > I hate to bring this up, but it's not just a historical issue. The version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings (e.g., {"foo":1e100000000000000000000000}). In fact, just a few weeks ago I sent a private email to someone about a massive vulnerability in a service (obviously not going to point out which one). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Mar 23 16:30:50 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 23 Mar 2015 18:30:50 +0200 Subject: wither the Platform In-Reply-To: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: <55103FBA.7050807@ro-che.info> On 23/03/15 17:19, Richard Eisenberg wrote: > Forgive me, all, for asking what many may think a silly question, but I must ask: > > What's wrong with the platform? It solves a problem few people seem to have. Most people want a compiler (ghc), a package manager (cabal), and libraries they can install (hackage/stackage). Instead, they are being sold HP which has its own versioning, releases on its own irregular schedule, and brings a small arbitrary set of packages frozen at an arbitrary point in time. These packages often interfere with users' desire to install their own packages. Roman From mietek at bak.io Mon Mar 23 16:32:42 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 16:32:42 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> On 2015-03-22, at 15:59, Michael Snoyman wrote: > 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. > 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. > I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. I?d be very happy to contribute to this effort. In fact, I?ve already spent some of time addressing these issues. Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs ? on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap. Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time?) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager. Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From nbouscal at gmail.com Mon Mar 23 17:06:21 2015 From: nbouscal at gmail.com (Nathan Bouscal) Date: Mon, 23 Mar 2015 10:06:21 -0700 Subject: wither the Platform In-Reply-To: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> References: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> Message-ID: Richard: The problem isn't the age itself, but rather the compatibility problems that age introduces. It can be quite difficult as a new user to get all of the libraries you want to use to play well with the platform. There's usually a way to make it work if you know what you're doing, but the platform is largely targeted at those who don't. This is particularly bad because library compatibility problems are inherently annoying to solve, or at least they feel that way to me. I think Gershom framed the problem well. From the discussion, it sounds like there are a lot of potential solutions, mostly in the category of "re-conceive the platform". On Mon, Mar 23, 2015 at 9:32 AM, Mi?tek Bak wrote: > On 2015-03-22, at 15:59, Michael Snoyman wrote: > > > 2. A method for installing GHC and build tools. I personally think that > it makes sense to separate out this aspect of the platform from all others. > MinGHC is an example of such a project: a minimal set of functionality for > bootstrapping a more complete Haskell development environment. > > 3. Prebuilt binary package databases. As I've mentioned in the past, and > others have here, there are problems with the current approach of putting > the packages in the global package database. I'd personally rather see this > aspect of the platform give way to more robust solutions. > > > > I think a smaller task force dedicated to improving the tooling > situation is the best next step, and I'd be happy to kick off such an > effort with other interested individuals. > > I?d be very happy to contribute to this effort. In fact, I?ve already > spent some of time addressing these issues. > > Halcyon already provides a method for installing GHC, cabal-install, > build-tools, and other Haskell programs ? on OS X, and many Linux > distributions. FreeBSD and Windows are on the roadmap. > > Additionally, Halcyon allows you to declare native OS libraries as > build-time (or run-time?) dependencies for Haskell programs. They will be > installed into a user-controlled directory, by wrapping around the native > OS package manager. > > Currently, this is supported on Debian-based and RedHat-based Linux > distributions, which partially implements a long-standing cabal-install > feature request: > https://github.com/mietek/halcyon/issues/38 > https://github.com/haskell/cabal/issues/571 > > See the Haskell Language source code for an example: > https://halcyon.sh/examples/#haskell-language > > See the Halcyon reference for details: > https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages > https://halcyon.sh/reference/#halcyon_extra_os_packages > > > -- > Mi?tek > https://mietek.io > > > > _______________________________________________ > 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 gershomb at gmail.com Mon Mar 23 17:19:34 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 13:19:34 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley wrote: > > I don't understand this attitude. You say that neither new users nor package > authors agree with your stance on the HP, so you want to force their hands. > Presumably package authors know what they're doing for themselves, and the > majority of evidence we have is that new users who stick with the language > do not like the way the HP works > . No, this is not what I said. I was explaining that it rather difficult, even if we wanted to force their hands, to imagine that we could do so. I will say that I do not share your belief that package authors know what they are doing, in general. If they did, I would imagine that nearly all packages would ensure they would work with the current platform. But getting programmers to all agree on something like that is herding cats, and all it takes is a few people saying "feh on the platform" but nonetheless producing otherwise good packages that come into widespread use to _in general_ mean that many packages which directly or indirectly want to use those dependencies must also now split off from support for the platform. So I agree that people have voted with their feet, and we need to catch up to that. In fact, it seems to me from this discussion that there are only _two_ things we need to do to make the platform the recommended install path for all platforms again: 1) Incorporate the improvements to windows builds that have been pioneered by the MinGHC project (in particular so that platform-installed windows ghc can build the network package properly, and perhaps even the GL stuff). 2) Address the problem that in a sandbox you will get a different install plan depending on your global package db. I would suggest this be done by setting a default preference of the sandbox to ignore global packages, and allow that to be overridden with an easily configurable flag or setting or the like. That way, new users can pay the longer compile price for a guaranteed-safer experience, and more experienced users can choose to use / build up a broader library of packages they can share across sandboxes. (Certainly some "nix-like tricks" in cabal could also help address the repeated builds problem, but a flag can be implemented much more quickly as a short-term measure). All that said, I think it would _still_ be better if more package authors paid attention to backwards-compatibility across releases, and it would _still_ be better for new users if they didn't go off and bash their heads against the newest and least stable packages around. But that is indeed a different problem. Cheers, Gershom From gershomb at gmail.com Mon Mar 23 17:31:08 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 13:31:08 -0400 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones wrote: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. My understanding is that the problem Yitz is discussing is much more straightforward and easy to fix. The issue is that if I have an "empty" global package db and enter a sandbox and cabal-install something, then I will get one package install plan. But if I have a "well populated" package db, then attempt to cabal-install something in the sandbox, the plan will attempt to use the packages from that global db, and so will often be a different, and perhaps worse plan (especially if it runs into quirks in the solver). This is discussed on the associated reddit thread here: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7 As I proposed on the main email thread, I think it would make sense to make the easy, default option the one which, in sandboxes, effectively ignores the global db for solving. This leads to more duplication and longer build times, but it is safer. However, we should have an easy setting/flag (to be set when initializing a sandbox or any time thereafter) which can switch the preference over to preferring to use already installed versions in the global db. That way, new users can, naively, get a _lot_ of isolation with sandboxes, and those who know what they are doing can opt out in order to reduce duplication of installs and cut down on build times. Addition of a `prefer-global-db` flag and a good default setting for it (i.e., false) seems to me like it would resolve the _central_ issue people have with the platform, and situate us well to unilaterally recommend it as the default install option. Cheers, Gershom From mietek at bak.io Mon Mar 23 18:17:11 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 18:17:11 +0000 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: On 2015-03-23, at 18:13, Andrew Farmer wrote: > I personally just download the latest bindist from the GHC site and > bootstrap cabal myself. Partly this is because my work requires me to > have the latest GHC, so maybe I'm not in the HP's target demographic. > That said, I would love if there was a platform that just did that (+ > whatever is needed to get that to work). Maybe at the end of the > minimal install, give me a choice between stackage and hackage and set > the remote-repo in my cabal file appropriately. I?m happy to say `halcyon install --cabal-remote-repo=?` does just that. See the Halcyon tutorial and reference for details: https://halcyon.sh/tutorial/#install-ghc-and-cabal https://halcyon.sh/reference/#halcyon_cabal_remote_repo -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 23 20:13:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 20:13:53 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>, Message-ID: <1427141632771.55413@microsoft.com> But I'm hazy about why sandboxes are needed at all. As I understand it, they were invented to solve the very problem that is now solved (if only Cabal could take advantage of it). Simon ________________________________________ From: Gershom B Sent: 23 March 2015 17:31 To: Simon Peyton Jones Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones wrote: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. My understanding is that the problem Yitz is discussing is much more straightforward and easy to fix. The issue is that if I have an "empty" global package db and enter a sandbox and cabal-install something, then I will get one package install plan. But if I have a "well populated" package db, then attempt to cabal-install something in the sandbox, the plan will attempt to use the packages from that global db, and so will often be a different, and perhaps worse plan (especially if it runs into quirks in the solver). This is discussed on the associated reddit thread here: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7 As I proposed on the main email thread, I think it would make sense to make the easy, default option the one which, in sandboxes, effectively ignores the global db for solving. This leads to more duplication and longer build times, but it is safer. However, we should have an easy setting/flag (to be set when initializing a sandbox or any time thereafter) which can switch the preference over to preferring to use already installed versions in the global db. That way, new users can, naively, get a _lot_ of isolation with sandboxes, and those who know what they are doing can opt out in order to reduce duplication of installs and cut down on build times. Addition of a `prefer-global-db` flag and a good default setting for it (i.e., false) seems to me like it would resolve the _central_ issue people have with the platform, and situate us well to unilaterally recommend it as the default install option. Cheers, Gershom From duncan.coutts at googlemail.com Mon Mar 23 22:07:32 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:07:32 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1427148452.11324.439.camel@dunky.localdomain> On Mon, 2015-03-23 at 08:45 +0000, Simon Peyton Jones wrote: > Dear Cabal developers > > You'll probably have seen the thread about the Haskell Platform. > > Among other things, this point arose: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. > > But some time now GHC has allowed multiple versions of the same > package (compiled against different dependencies) to be installed > simultaneously. That's technically true of existing ghc versions, though ghc-pkg does not directly allow registering multiple instances of the same version of a package. As of 7.10 we can actually use ghc-pkg to register multiple instances, using ghc-pkg register --enable-multi-instance Also since 7.10 we can have "environment" files that say what packages to expose. There can be a per-user default one, or per-user named ones (which can be used via the ghc command line or via env var), or local environments in a directory. While Cabal has always built things with consistent deps and solved the problem of "which ByteString do I mean", the same has not been true for GHCi. With this new environment mechanism Cabal can create the environments and then when the user runs ghc/ghci then they get the set of packages previously set up by Cabal. Elsewhere in this thread you say: > What you want is for the confusing behaviour to be true of GHCi too. > Well that?s simple enough: ensure that the set of exposed packages (ie > the ones you say ?import M? for), is consistent in the same way. The > point is that I may need to install a bunch of packages to build a > program. If I?m using Cabal, none of those newly installed packages > need be exposed; I simply need them there so I can compile my program > (using Cabal). But at the moment I can?t do that. Yes, that is exactly what these environment files are intended for. Myself and Edsko implemented these features (for the IHG) to enable future Cabal versions to take the multi instance approach fully. > So all we need to do is to fix Cabal to allow it too, and thereby kill > of a huge class of cabal-hell problems at one blow. With these features now implemented in GHC we're in a position to turn attention to Cabal to make use of them. > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because > there are much bigger problems? Or because there is insufficient > effort available? Or what? There's a number of parts remaining to do. > Unless I'm way off beam, this "multiple installations of the same > package" thing has been a huge pain forever, and the solution is > within our grasp. What's stopping us grasping it? Yes, we're closer than ever. I covered more of the details in this blog post: http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ So some of the remaining parts: Cabal needs to assign proper installed package ids, like nix does. These should be based on the hash of all inputs to a package build. In particular that means a hash of the content of the sources. This is easy for tarballs but a bit harder to do accurately for unpacked build trees. There are some new UI issues to deal with. The user interface will have to make this issue of multiple consistent environments be explicit in the user interface. We need to know what env we are in, what is in it, what other envs are available and be able to switch between them. Suppose that we enforce that each environment be fully consistent. Then when I "cabal install Q" and it cannot find a solution to install everything in the current environment plus the one extra package such that they all have consistent deps, then what should it do? Suppose that Q really could be installed on its own, but cannot be installed consistently with the other things in this env. Should it suggest that you make a new environment? There are some details to work out here so that we don't make a confusing UI. There's also an unresolved issue about when we try to reuse existing installed dependencies. One approach is to say that we make install plans without considering what is already available in the package store, and then only re-use existing ones if the installed package Ids happen to match up. The other approach is to say that the solver should actively try to reuse installed instances when it can. The latter is what we do now, to try and reduce the number of reinstalls. But when there are dozens of versions available this is harder: we need to know more information to know if it is safe to re-use an existing instance. (There are examples where it's clearly not safe to reuse packages.) Or a pragmatic approach might be to try and reuse existing installed instances within the current environment but not actively try to reuse other instances available in the package store. On a related topic, along with the London HUG we're trying to organise a couple infrastructure hackathons in London. The aim would be to work on Cabal/Hackage related things. The plan is to have two hackathons 6-8 weeks apart, to get new people set up with projects at the first and to get things merged in the second. For Cabal, this project would be my focus, trying to get people to work on different aspects of it. I gave a talk at the London HUG recently about getting involved with hacking on Cabal/Hackage. Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:10:09 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:10:09 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <1427141632771.55413@microsoft.com> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> , <1427141632771.55413@microsoft.com> Message-ID: <1427148609.11324.441.camel@dunky.localdomain> On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote: > But I'm hazy about why sandboxes are needed at all. As I understand > it, they were invented to solve the very problem that is now solved > (if only Cabal could take advantage of it). Yes, the nix approach would subsume sandboxes. I cover this in this post http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:18:57 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:18:57 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <1427149137.11324.444.camel@dunky.localdomain> On Sun, 2015-03-22 at 09:17 +0000, Neil Mitchell wrote: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. > > Nowadays I use https://github.com/fpco/minghc which can actually > install network, and I've had zero problems. Can we just include this fix into the platform installers? As Mark says, the Platform has decent automated build & test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to "min" vs "max" installers. Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:24:43 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:24:43 +0000 Subject: wither the Platform In-Reply-To: <87h9tdpder.fsf@gnu.org> References: <87h9tdpder.fsf@gnu.org> Message-ID: <1427149483.11324.447.camel@dunky.localdomain> On Sun, 2015-03-22 at 10:52 +0100, Herbert Valerio Riedel wrote: > My biggest complaint about the current HP is that it pollutes the global > package database with additional packages which leak into `cabal > sandbox`es. This causes `cabal sandbox` to provide quite different > sandbox environments for HP environments compared to a non-HP > environment without those additional packages pre-installed. > > Currently GHC/Cabal knows about a global package db and a user package > db (the user pkg db is is what gets replaced/shadowed by cabal > sandboxes). Maybe we need a 3rd package db sitting between the global > and the user package db that interacts better with cabal sandboxes? I think this is a good idea. As far as I can see there's no conflict between the advocates of mini and maxi installers (as aimed at new users) except for this behaviour of new sandboxes. All we need to do is make "cabal sandbox init" start with a minimal package set, rather than taking the global package db. It's true that the ghc/platform installers could help with this, e.g. by shipping an environment file (a new 7.10 feature) that lists all the core packages, and cabal-install could use this as a basis for new sandboxes. Duncan From ndmitchell at gmail.com Mon Mar 23 22:28:43 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon, 23 Mar 2015 22:28:43 +0000 Subject: wither the Platform In-Reply-To: <1427149137.11324.444.camel@dunky.localdomain> References: <1427149137.11324.444.camel@dunky.localdomain> Message-ID: >> Nowadays I use https://github.com/fpco/minghc which can actually >> install network, and I've had zero problems. > > Can we just include this fix into the platform installers? Yes. MinGHC was an experiment in seeing if we could do a Windows installer that worked with Network. We can, so the platform should. However, MinGHC has a few other advantages. It provides a switcher so you can put all the switchers on your PATH and type "minghc-7.8.3" to get that version of GHC selected. Again, the platform could gain that feature. MinGHC also ships with GHC 7.2, 7.4, 7.6 and 7.8. Hopefully as soon as 7.10 is out within days we'll have a MinGHC for it. I'd also really like to start shipping MinGHC installers for GHC release candidates and even nightly GHC release candidates. > As Mark says, > the Platform has decent automated build & test infrastructure so it > shouldn't be that hard. As I understand it the network problem is just > to do with how much of mingwin we include and not really related to > "min" vs "max" installers. Indeed, it has nothing to do with how many packages are shipped. As long as my installer ships with enough to install the packages I care about, then I don't care about min vs max. That said, all I really care is what GHC the platform includes, everything else is redundant (to me). As such having a link to a platform with each GHC version would be handy. Thanks, Neil From duncan.coutts at googlemail.com Mon Mar 23 22:33:15 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:33:15 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <1427148609.11324.441.camel@dunky.localdomain> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> , <1427141632771.55413@microsoft.com> <1427148609.11324.441.camel@dunky.localdomain> Message-ID: <1427149995.11324.448.camel@dunky.localdomain> On Mon, 2015-03-23 at 22:10 +0000, Duncan Coutts wrote: > On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote: > > But I'm hazy about why sandboxes are needed at all. As I understand > > it, they were invented to solve the very problem that is now solved > > (if only Cabal could take advantage of it). > > Yes, the nix approach would subsume sandboxes. > > I cover this in this post > http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ Oops, permanent link: http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/ From duncan.coutts at googlemail.com Mon Mar 23 22:51:17 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:51:17 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <1427151077.11324.459.camel@dunky.localdomain> On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. There was a big argument about this. I was on the loosing side. :-) > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. I think it is worth it, and the issues that people are complaining about wrt the platform vs minimal installers can be fixed. > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. Right, I think there's still a great deal of value in having a simple recommendation for new users. One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised. > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: Well, the people who like it don't really complain. But yes, things need improving. > *1) Abandon the Platform.* GHC is release in source and binary form. Other > package various installers, with more or less things, for various OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together. We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often. On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict. But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset). Duncan From mwm at mired.org Tue Mar 24 03:07:42 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 23 Mar 2015 22:07:42 -0500 Subject: wither the Platform In-Reply-To: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg wrote: > Forgive me, all, for asking what many may think a silly question, but I must ask: > What's wrong with the platform? You know, I don't think we ever really saw an answer to this. Well, given that we're looking at ways to make it easier to work with packages that aren't in HP when you have HP installed, indicating that some people think what's wrong is that it's hard to use non-HP libraries with HP. I don't think this is what's wrong with HP, I think it's a symptom of what's wrong. That's just making it easy to work around having installed the platform. > One non-answer to this question: > - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong. I think this is another symptom. Yes, there are some people who always want the newest, shiniest thing. A system where you bundle up some best-of set of libraries won't make them happy, unless maintenance of the libraries moves into HP, or at least has releases coordinated with it. I don't have to have newest and shiniest. I just want to get my problem solved. But I still found that, as soon as I moved beyond doing textbook exercises to trying to solve my problems - not industrial grade solutions, just thing that would work for me - the packages I wanted to use weren't part of HP. Which led to wanting to install those packages on top of HP, which led to all the problems the current discussions are trying to solve, which led to just installing GHC and cabal. I didn't have that problem with Python or Clojure. I didn't run into it with Python until I was building enterprise-class systems. I ran into other issues that made me drop Clojure before I ran into this one. So, why weren't the packages I wanted to install in the platform? If it's really "batteries included" as the haskell.org/platform/contents.html says, shouldn't they be there well beyond just doing textbook exercises? Well, how do you find packages to solve a problem in Haskell? I bet most of you thought "Hackage" or "Hoogle". Maybe a few of you though "Google", and even fewer thought "Stackage". Which means you're probably checking a disorganized, random collection, may well be checking anything on the web, and at best are searching a curated library that's trying to do part of what HP should be doing. For Python, the answer is "search the Standard library docs". For Clojure, it's "search clojure.org". And for the people who habitually go to google for every search who are looking for things in the python standard library or the clojure library, the first links that come back will point back to those docs, not into an archive whose barrier to inclusion is compilation. And this creates secondary and tertiary problems. With Python and Clojure, in the cases where I do need something that's not in the libraries, chances are it's built on top of things that are, because those are the things people will tend to use. With Haskell, that's not the case. And should I need multiple such things - they'll probably depend on the same set of libraries. Net result: nearly two decades of writing Python code, from version 1.4 back in the last century to version 3.4 this year, I never ran into library dependency issues. So, why isn't the answer for Haskell "search the platform docs"? Maybe because there's no way to do that? If there is, I couldn't find it. There is documentation for the libraries, but it's just the haddock docs that are available in the other archives. Adding a search to the platform docs would be a nice step, but it won't solve the problem. I don't think something as integrated as python's standard library is possible, as being in the python standard library means doing maintenance and releases on CPython's schedule. Something like Clojure might be possible, with a small standard set of libraries, and a curated set that builds on that, and then the wide open archive. And of course, the platform shipping with Cabal configured to search only the curated archive by default. But that won't solve the problem unless there's broad agreement in the community that these are the places to search for Haskell packages. Otherwise, people trying to get started will wind up seeing a set of choices they really shouldn't be making yet. From davean at xkcd.com Tue Mar 24 04:33:11 2015 From: davean at xkcd.com (davean) Date: Tue, 24 Mar 2015 00:33:11 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: > > I didn't have that problem with Python or Clojure. I didn't run into > it with Python until I was building enterprise-class systems. I ran > into other issues that made me drop Clojure before I ran into this > one. > Well, it also was standard python practice to monkey patch the libraries to fix deficiencies, like the inability to call "PUT" with the standard HTTP lib. Where as I see people picking the right X library to have a style of programming that makes their code easy to follow in Haskell instead of "just making it work". Now I probably see a highly non-random selection of programmer's work in Haskell. I'd say what I see is not what you propose at all though. I see 2 or 3 HTTP client libs used in the same (large-ish) project even, because each of them has different code it makes easier and prettier. One of Haskell's attraction to me is the work done in selecting good abstractions and approaches to problems refining the method used. This will inherently lead to diversity. Sometimes its bad. but its part of not just getting the job done, but instead trying to do it better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Tue Mar 24 06:23:44 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Tue, 24 Mar 2015 01:23:44 -0500 Subject: Fixing Fix In-Reply-To: References: Message-ID: <20150324062344.GA1832@mintha> On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: > There are a good number of different packages that define either > > newtype Fix f = Fix (f (Fix f)) > > or something equivalent except for naming. Most of the name variation > is in the name of the data constructor and/or record selector. This > does not look like an ideal situation to me. Most problematically, the > only way to convert one to another is with unsafeCoerce. > > I think it would be rather nice to choose one canonical place for this > definition, and let everyone else use it. +1 I propose module Data.Fix where newtype Fix f = Fix { unFix :: f (Fix f) } Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> Fix f -> Fix g there. From voldermort at hotmail.com Tue Mar 24 08:48:07 2015 From: voldermort at hotmail.com (Jeremy) Date: Tue, 24 Mar 2015 01:48:07 -0700 (MST) Subject: wither the Platform In-Reply-To: <55103FBA.7050807@ro-che.info> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> <55103FBA.7050807@ro-che.info> Message-ID: <1427186887290-5767530.post@n5.nabble.com> Roman Cheplyaka-2 wrote > It solves a problem few people seem to have. > > Most people want a compiler (ghc), a package manager (cabal), and > libraries they can install (hackage/stackage). > > Instead, they are being sold HP which has its own versioning, releases > on its own irregular schedule, and brings a small arbitrary set of > packages frozen at an arbitrary point in time. These packages often > interfere with users' desire to install their own packages. +100 I've avoided HP for just these reasons, only using it on Windows for the installer, and will probably use MinGHC for future installs. The platform's primary goal was to mimic the comprehensive standard libraries shipped with other languages (aka batteries included). This seemed like a good idea at the time, but a fundamental difference between picking "approved" libraries off hackage and "real" standard libraries has made it unusable for real work. New versions of Python's batteries are released with a new version of the interpreter (i.e. the Python platform). New releases of the Java standard libraries are released with new versions of the JDK. New releases of the .NET framework are tied to a new version of the .NET platform. New libraries are uploaded to Hackage whenever the authors feel like it, with whatever dependencies they want. While HP was trying to treat a blessed, very small subset of Hackage (at specific versions) as if it was part of a co-ordinated GHC platform release, Microsoft have been moving in the opposite direction, moving non-essential .NET libraries into out-of-band NuGet packages. In summary, we should stop making installers that fossilize a handful of packages into the global package database, and concentrate on how we can help users identify the best packages for what they want to do. (Task-oriented wiki pages and adding reviews to Hackage may help here.) If we want to help them avoid cabal-hell, this is a problem better solved by sandboxes and/or Stackage. -- View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767530.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From jeremy.odonoghue at gmail.com Tue Mar 24 12:17:12 2015 From: jeremy.odonoghue at gmail.com (Jeremy O'Donoghue) Date: Tue, 24 Mar 2015 12:17:12 +0000 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On 24 March 2015 at 03:07, Mike Meyer wrote: > On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg > wrote: > > Forgive me, all, for asking what many may think a silly question, but I > must ask: > > What's wrong with the platform? > > One non-answer to this question: > > - "It's always out-of-date." This statement, while true, isn't a direct > indication that something is wrong. > > I think this is another symptom. Yes, there are some people who always > want the newest, shiniest thing. A system where you bundle up some > best-of set of libraries won't make them happy, unless maintenance of > the libraries moves into HP, or at least has releases coordinated with > it. > +100 For me, HP is the only Haskell environment I will consider because: 1) Code I write needs to run on Mac (where it is written), Windows and Linux (where it is usually used). None of the 'build it yourself' alternatives gives a way to ensure, with confidence, that I have the same platform on each of my machines. 2) Life is too short to spend time messing around with things that won't build, out of date 'install from source' instructions and the like. 3) Haskell is not my core day job. HP always works, and is stable, predictable and documented. However, it seems to me that each HP release is essentially a snapshot, and is not really maintained thereafter. What I would love to see is for HP releases to have some level of maintenance. In particular, Michael Snowman's comment earlier that: "the version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings" goes to the heart of the matter for me. > I didn't have that problem with Python or Clojure. I didn't run into > it with Python until I was building enterprise-class systems. I ran > into other issues that made me drop Clojure before I ran into this > one. > > So, why weren't the packages I wanted to install in the platform? If > it's really "batteries included" as the > haskell.org/platform/contents.html says, shouldn't they be there well > beyond just doing textbook exercises? > I think there are a few issues here, some of which are probably specific to the Haskell community. - There are not many Haskell users in the enterprise space who are in a position to make significant contributions of reasonably complete and 'battle tested' libraries for common problems. The OCaml community is very well served by the efforts of Jane Street in this respect. - Related to the above, there are many libraries that are incomplete (as typically the contributor will solve the subset of the problem that relates to his/her needs. - In some cases, people simply find better ways to do something that was previously messy, and this renders older (and otherwise stable) APIs and libraries unattractive. An example would be the way that Lenses have hugely simplified working on certain types of problem. - There is a huge gap in understanding between even moderately capable Haskell programmers and those at the cutting edge. I believe that this could in many cases be filled with better documentation, but the fact remains that some packages have APIs which are designed at a level of type abstraction that is unnatural to me, which makes them very hard to use. As an example, when I look at the package documentation for Data.Lens.Partial.Common, I have no clue as to where to even start. Perhaps this is a reason why there are now almost as many Lens tutorials as Monad tutorials (and with a regrettably similarly poor signal to noise ratio). OTOH, maybe my IQ is just too low to be a Haskeller :-( - I think, perhaps, that Haskell shares with Lisp communities the tendency that "we have a tool of great power available to us, so it is easier to roll our own solutions than use someone else's". I understand this, but the overall community is much better served where it can get behind a single library in each area that covers all major use cases, and which is well documented, maintained, builds cleanly and runs on all major platforms and generally remains backward compatible on upgrade. I'm not sure if I am really offering any solutions here, but FWIW, I would advocate: - HP probably does need to become smaller,of only because we do not all agree on what 'Batteries Included' means for Haskell. - HP should be maintained, at least for critical bug fixes, until at least release of next HP + a short period (maybe 3 months). - I would love to see a community effort to develop (or select from existing libraries) 'one library to rule them all' in some of the critical areas. This effort would include comprehensive documentation for every function, a meaningful set of examples and a commitment to bug fixes. The Python Standard library would be a good place to start in terms of which libraries are most needed - obviously not for API design! Finally, to Mark and the HP team: the work you have done over the years is outstanding. The work of patiently pulling together inputs from many moving targets, testing on multiple platforms and releasing is patient, challenging and unglamorous. My sincere thanks to you all. Best regards Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Tue Mar 24 13:57:04 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 24 Mar 2015 09:57:04 -0400 Subject: Type roles for UArray? Message-ID: So I was working on porting my libraries to work for GHC 7.10 and I ran into a snag. Unlike the concrete type Data.Array.Array, the concrete type Data.Array.Unboxed.UArray is defined as being nominal in the second type argument? is this a bug? If not, then why must it be nominal? Shouldn't (UArray a New) and (UArray a Old) have the same representation in memory? Using unsafeCoerce has always been safe here in the past... -- Live well, ~wren From rwbarton at gmail.com Tue Mar 24 14:15:30 2015 From: rwbarton at gmail.com (Reid Barton) Date: Tue, 24 Mar 2015 10:15:30 -0400 Subject: Type roles for UArray? In-Reply-To: References: Message-ID: On Tue, Mar 24, 2015 at 9:57 AM, wren romano wrote: > So I was working on porting my libraries to work for GHC 7.10 and I > ran into a snag. Unlike the concrete type Data.Array.Array, the > concrete type Data.Array.Unboxed.UArray is defined as being nominal in > the second type argument? is this a bug? > No, see https://ghc.haskell.org/trac/ghc/ticket/9220. > If not, then why must it be nominal? Shouldn't (UArray a New) and > (UArray a Old) have the same representation in memory? Using > unsafeCoerce has always been safe here in the past... > It wasn't and isn't necessarily safe (though in some cases it is safe). The IArray instances for Old and New could be unrelated (for example, they could use a different amount of space per element). Knowing that Old and New are related by a coercion means that the heap representation of actual values of types Old and New are the same, but that says nothing about how these values are stored in an unboxed array. Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Tue Mar 24 14:19:48 2015 From: voldermort at hotmail.com (Jeremy) Date: Tue, 24 Mar 2015 07:19:48 -0700 (MST) Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: <1427206788567-5767542.post@n5.nabble.com> Jeremy O'Donoghue wrote > 1) Code I write needs to run on Mac (where it is written), Windows and > Linux (where it is usually used). None of the 'build it yourself' > alternatives gives a way to ensure, with confidence, that I have the same > platform on each of my machines. Why not just install GHC x.y.z and cabal freeze? (You could also use a stackage snapshot.) -- View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767542.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From winterkoninkje at gmail.com Tue Mar 24 14:25:23 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 24 Mar 2015 10:25:23 -0400 Subject: Type roles for UArray? In-Reply-To: References: Message-ID: On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton wrote: > On Tue, Mar 24, 2015 at 9:57 AM, wren romano > wrote: >> >> So I was working on porting my libraries to work for GHC 7.10 and I >> ran into a snag. Unlike the concrete type Data.Array.Array, the >> concrete type Data.Array.Unboxed.UArray is defined as being nominal in >> the second type argument? is this a bug? > > No, see https://ghc.haskell.org/trac/ghc/ticket/9220. Fair enough. To be clearer, my actual goal is to automatically derive the (IArray UArray) instance for a newtype. The newtype has semantic content (like Sum or Product), but no representational content (i.e., New and Old have the same size and the same valid bit patterns). This worked fine in GHC 7.8 and prior, and should still be fine since it doesn't run into the sorts of issues raised by that bug report. Again, the goal is to automatically derive the instance rather than doing it manually, since I really want to just inherit the underlying instance at the new type. -- Live well, ~wren From winterkoninkje at gmail.com Tue Mar 24 14:37:07 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 24 Mar 2015 10:37:07 -0400 Subject: Fixing Fix In-Reply-To: <20150324062344.GA1832@mintha> References: <20150324062344.GA1832@mintha> Message-ID: On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: > There are a good number of different packages that define either > > newtype Fix f = Fix (f (Fix f)) > > or something equivalent except for naming. Most of the name variation > is in the name of the data constructor and/or record selector. This > does not look like an ideal situation to me. Most problematically, the > only way to convert one to another is with unsafeCoerce. > > I think it would be rather nice to choose one canonical place for this > definition, and let everyone else use it. +1 On Tue, Mar 24, 2015 at 2:23 AM, M Farkas-Dyck wrote: > I propose > > module Data.Fix where I'd move it to Data.Functor.Fix, so as to help clean up the Data.Everything situation > newtype Fix f = Fix { unFix :: f (Fix f) } One issue with this particular definition is that the derived Show instance (if any) is quite verbose and ugly. For this sort of newtype construction, I typically define unFoo as a function rather than using the record notation precisely to clean up such noise. > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> Fix f -> Fix g there. The big question here is what to call it. And, really, we probably want all the functions from unification-fd:Data.Functor.Fixedpoint (perhaps excluding all the y- functions). -- Live well, ~wren From eir at cis.upenn.edu Tue Mar 24 14:45:29 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 24 Mar 2015 10:45:29 -0400 Subject: Type roles for UArray? In-Reply-To: References: Message-ID: <53B7525B-8EDD-4E46-9B78-CE6EE09605B9@cis.upenn.edu> The notes to #9220 explain this fairly well, I think. But, Wren's desire is reasonable. The real reason that GND can't work here is that the safety condition lives outside the type system. It seems to me like one way forward is to allow an unsafe GND, via some pragma. It would be dead-easy to implement (modulo surface syntax): just change `coerce` to `unsafeCoerce` in the produced code. Richard On Mar 24, 2015, at 10:25 AM, wren romano wrote: > On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton wrote: >> On Tue, Mar 24, 2015 at 9:57 AM, wren romano >> wrote: >>> >>> So I was working on porting my libraries to work for GHC 7.10 and I >>> ran into a snag. Unlike the concrete type Data.Array.Array, the >>> concrete type Data.Array.Unboxed.UArray is defined as being nominal in >>> the second type argument? is this a bug? >> >> No, see https://ghc.haskell.org/trac/ghc/ticket/9220. > > Fair enough. > > > To be clearer, my actual goal is to automatically derive the (IArray > UArray) instance for a newtype. The newtype has semantic content (like > Sum or Product), but no representational content (i.e., New and Old > have the same size and the same valid bit patterns). This worked fine > in GHC 7.8 and prior, and should still be fine since it doesn't run > into the sorts of issues raised by that bug report. Again, the goal is > to automatically derive the instance rather than doing it manually, > since I really want to just inherit the underlying instance at the new > type. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From david.feuer at gmail.com Tue Mar 24 14:54:23 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 24 Mar 2015 10:54:23 -0400 Subject: Type roles for UArray? In-Reply-To: <53B7525B-8EDD-4E46-9B78-CE6EE09605B9@cis.upenn.edu> References: <53B7525B-8EDD-4E46-9B78-CE6EE09605B9@cis.upenn.edu> Message-ID: I would be very much opposed, personally, to such an unsafe global pragma. Something like deriving instance {-# UnsafeNewtypeDerivation #-} Foo Bar would seem more reasonable. I'd also really like to see a less awkward story for these unboxed vector types, ideally one that would also enable unboxed non-vector containers more easily. I imagine I'm not the only one interested in unboxed priority queues and maps and sets and things. On Mar 24, 2015 10:45 AM, "Richard Eisenberg" wrote: > The notes to #9220 explain this fairly well, I think. > > But, Wren's desire is reasonable. The real reason that GND can't work here > is that the safety condition lives outside the type system. > > It seems to me like one way forward is to allow an unsafe GND, via some > pragma. It would be dead-easy to implement (modulo surface syntax): just > change `coerce` to `unsafeCoerce` in the produced code. > > Richard > > On Mar 24, 2015, at 10:25 AM, wren romano > wrote: > > > On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton > wrote: > >> On Tue, Mar 24, 2015 at 9:57 AM, wren romano > >> wrote: > >>> > >>> So I was working on porting my libraries to work for GHC 7.10 and I > >>> ran into a snag. Unlike the concrete type Data.Array.Array, the > >>> concrete type Data.Array.Unboxed.UArray is defined as being nominal in > >>> the second type argument? is this a bug? > >> > >> No, see https://ghc.haskell.org/trac/ghc/ticket/9220. > > > > Fair enough. > > > > > > To be clearer, my actual goal is to automatically derive the (IArray > > UArray) instance for a newtype. The newtype has semantic content (like > > Sum or Product), but no representational content (i.e., New and Old > > have the same size and the same valid bit patterns). This worked fine > > in GHC 7.8 and prior, and should still be fine since it doesn't run > > into the sorts of issues raised by that bug report. Again, the goal is > > to automatically derive the instance rather than doing it manually, > > since I really want to just inherit the underlying instance at the new > > type. > > > > -- > > Live well, > > ~wren > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Tue Mar 24 14:58:36 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 24 Mar 2015 15:58:36 +0100 Subject: Fixing Fix In-Reply-To: <20150324062344.GA1832@mintha> References: <20150324062344.GA1832@mintha> Message-ID: On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck wrote: > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >> There are a good number of different packages that define either >> >> newtype Fix f = Fix (f (Fix f)) >> >> or something equivalent except for naming. Most of the name variation >> is in the name of the data constructor and/or record selector. This >> does not look like an ideal situation to me. Most problematically, the >> only way to convert one to another is with unsafeCoerce. >> >> I think it would be rather nice to choose one canonical place for this >> definition, and let everyone else use it. > > +1 > > I propose > > module Data.Fix where > > newtype Fix f = Fix { unFix :: f (Fix f) } I'm used to newtype Fix f = In { out : f (Fix f) } But all the other suggestions look fine to me, too. I've also often used this variation: newtype HFix f a = In { out :: f (HFix f) a } This allows you to take the fixed point of e.g. monad stacks and indexed types. The function you propose below can then be a type class function of an indexed Functor class: type f :-> g = forall a. f a -> g a class HFunctor f where hmap :: (a :-> b) -> f a :-> g a Does this deserve a place somewhere as well? Or is it too specialized? > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> Fix f -> Fix g there. Some variation of 'map' seems sensible, like 'hmap' (but see above) or 'mapFix'. Erik From eir at cis.upenn.edu Tue Mar 24 14:59:56 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 24 Mar 2015 10:59:56 -0400 Subject: Type roles for UArray? In-Reply-To: References: <53B7525B-8EDD-4E46-9B78-CE6EE09605B9@cis.upenn.edu> Message-ID: <75F26337-B2ED-4A61-9552-7B3E9CD66535@cis.upenn.edu> I wasn't thinking of a global pragma -- something much closer to what you propose. I actually think we should go further and come up with a unified story around different "deriving" mechanisms. GHC currently has 3: 1) Haskell98-style, including extensions like DeriveFunctor. These "derivings" are baked in. 2) GND 3) DeriveAnyClass, a new extension, intended to be used with generics, that produces an empty instance declaration. The methods are intended to be filled in by (perhaps generic) default implementations. This thread proposes a new mechanism: unsafeGND. And perhaps more are waiting in the wings. Users should be able to specify the mechanism, and if that mechanism is unavailable, GHC should error. When more than one mechanism is non-trivially applicable, GHC should error. (The "non-trivial" is there to rule out errors for, say, deriving Eq via Haskell98 or via GND: both result in the same behavior.) I leave it to others to bikeshed about syntax. :) Richard On Mar 24, 2015, at 10:54 AM, David Feuer wrote: > I would be very much opposed, personally, to such an unsafe global pragma. Something like > > deriving instance {-# UnsafeNewtypeDerivation #-} Foo Bar > > would seem more reasonable. I'd also really like to see a less awkward story for these unboxed vector types, ideally one that would also enable unboxed non-vector containers more easily. I imagine I'm not the only one interested in unboxed priority queues and maps and sets and things. > > On Mar 24, 2015 10:45 AM, "Richard Eisenberg" wrote: > The notes to #9220 explain this fairly well, I think. > > But, Wren's desire is reasonable. The real reason that GND can't work here is that the safety condition lives outside the type system. > > It seems to me like one way forward is to allow an unsafe GND, via some pragma. It would be dead-easy to implement (modulo surface syntax): just change `coerce` to `unsafeCoerce` in the produced code. > > Richard > > On Mar 24, 2015, at 10:25 AM, wren romano wrote: > > > On Tue, Mar 24, 2015 at 10:15 AM, Reid Barton wrote: > >> On Tue, Mar 24, 2015 at 9:57 AM, wren romano > >> wrote: > >>> > >>> So I was working on porting my libraries to work for GHC 7.10 and I > >>> ran into a snag. Unlike the concrete type Data.Array.Array, the > >>> concrete type Data.Array.Unboxed.UArray is defined as being nominal in > >>> the second type argument? is this a bug? > >> > >> No, see https://ghc.haskell.org/trac/ghc/ticket/9220. > > > > Fair enough. > > > > > > To be clearer, my actual goal is to automatically derive the (IArray > > UArray) instance for a newtype. The newtype has semantic content (like > > Sum or Product), but no representational content (i.e., New and Old > > have the same size and the same valid bit patterns). This worked fine > > in GHC 7.8 and prior, and should still be fine since it doesn't run > > into the sorts of issues raised by that bug report. Again, the goal is > > to automatically derive the instance rather than doing it manually, > > since I really want to just inherit the underlying instance at the new > > type. > > > > -- > > Live well, > > ~wren > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Mar 24 15:07:37 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 24 Mar 2015 17:07:37 +0200 Subject: Type roles for UArray? In-Reply-To: <75F26337-B2ED-4A61-9552-7B3E9CD66535@cis.upenn.edu> References: <53B7525B-8EDD-4E46-9B78-CE6EE09605B9@cis.upenn.edu> <75F26337-B2ED-4A61-9552-7B3E9CD66535@cis.upenn.edu> Message-ID: <55117DB9.2070505@ro-che.info> On 24/03/15 16:59, Richard Eisenberg wrote: > When more than one mechanism is non-trivially applicable, GHC should > error. (The "non-trivial" is there to rule out errors for, say, > deriving Eq via Haskell98 or via GND: both result in the same > behavior.) This happens all the time ? Show instance would differ from the standard derived one if GND'ed. But I certainly share your concerns. Roman From david.feuer at gmail.com Tue Mar 24 15:25:45 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 24 Mar 2015 11:25:45 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: I have no comment on your higher-order version (because I don't understand it yet), but the type you give for hmap looks unlikely. Did you mean hmap :: (g :-> h) -> f g :-> f h ? On Mar 24, 2015 10:58 AM, "Erik Hesselink" wrote: > On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck > wrote: > > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: > >> There are a good number of different packages that define either > >> > >> newtype Fix f = Fix (f (Fix f)) > >> > >> or something equivalent except for naming. Most of the name variation > >> is in the name of the data constructor and/or record selector. This > >> does not look like an ideal situation to me. Most problematically, the > >> only way to convert one to another is with unsafeCoerce. > >> > >> I think it would be rather nice to choose one canonical place for this > >> definition, and let everyone else use it. > > > > +1 > > > > I propose > > > > module Data.Fix where > > > > newtype Fix f = Fix { unFix :: f (Fix f) } > > I'm used to > > newtype Fix f = In { out : f (Fix f) } > > But all the other suggestions look fine to me, too. > > I've also often used this variation: > > newtype HFix f a = In { out :: f (HFix f) a } > > This allows you to take the fixed point of e.g. monad stacks and > indexed types. The function you propose below can then be a type class > function of an indexed Functor class: > > type f :-> g = forall a. f a -> g a > > class HFunctor f where > hmap :: (a :-> b) -> f a :-> g a > > Does this deserve a place somewhere as well? Or is it too specialized? > > > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> Fix f > -> Fix g there. > > Some variation of 'map' seems sensible, like 'hmap' (but see above) or > 'mapFix'. > > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Tue Mar 24 15:23:58 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Tue, 24 Mar 2015 10:23:58 -0500 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: <20150324152358.GA1057@mintha> On 24/03/2015 at 10:37:07 -0400, wren romano wrote: > On Tue, Mar 24, 2015 at 2:23 AM, M Farkas-Dyck wrote: > > I propose > > > > module Data.Fix where > > I'd move it to Data.Functor.Fix, so as to help clean up the > Data.Everything situation Good call. From hesselink at gmail.com Tue Mar 24 15:40:51 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 24 Mar 2015 16:40:51 +0100 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: Ugh, you're right, I renamed the variables and made a mistake. The outer variable should stay the same of course, your signature is correct. For a use site of HFix, see the multirec package [0], although that might not really clarify things :) We also have a use internally, but I just realized we can probably simplify that away. Regards, Erik [0] http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html On Tue, Mar 24, 2015 at 4:25 PM, David Feuer wrote: > I have no comment on your higher-order version (because I don't understand > it yet), but the type you give for hmap looks unlikely. Did you mean > > hmap :: (g :-> h) -> f g :-> f h ? > > On Mar 24, 2015 10:58 AM, "Erik Hesselink" wrote: >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck >> wrote: >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >> >> There are a good number of different packages that define either >> >> >> >> newtype Fix f = Fix (f (Fix f)) >> >> >> >> or something equivalent except for naming. Most of the name variation >> >> is in the name of the data constructor and/or record selector. This >> >> does not look like an ideal situation to me. Most problematically, the >> >> only way to convert one to another is with unsafeCoerce. >> >> >> >> I think it would be rather nice to choose one canonical place for this >> >> definition, and let everyone else use it. >> > >> > +1 >> > >> > I propose >> > >> > module Data.Fix where >> > >> > newtype Fix f = Fix { unFix :: f (Fix f) } >> >> I'm used to >> >> newtype Fix f = In { out : f (Fix f) } >> >> But all the other suggestions look fine to me, too. >> >> I've also often used this variation: >> >> newtype HFix f a = In { out :: f (HFix f) a } >> >> This allows you to take the fixed point of e.g. monad stacks and >> indexed types. The function you propose below can then be a type class >> function of an indexed Functor class: >> >> type f :-> g = forall a. f a -> g a >> >> class HFunctor f where >> hmap :: (a :-> b) -> f a :-> g a >> >> Does this deserve a place somewhere as well? Or is it too specialized? >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> Fix f >> > -> Fix g there. >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above) or >> 'mapFix'. >> >> Erik From ollie at ocharles.org.uk Tue Mar 24 16:20:42 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Tue, 24 Mar 2015 16:20:42 +0000 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: Higher order stuff is very useful, but I don't think it needs to belong in the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library will probably deal with this, when we have a GHC that's smart enough to understand it ;) - Ollie On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink wrote: > Ugh, you're right, I renamed the variables and made a mistake. The > outer variable should stay the same of course, your signature is > correct. > > For a use site of HFix, see the multirec package [0], although that > might not really clarify things :) We also have a use internally, but > I just realized we can probably simplify that away. > > Regards, > > Erik > > [0] > http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html > > On Tue, Mar 24, 2015 at 4:25 PM, David Feuer > wrote: > > I have no comment on your higher-order version (because I don't > understand > > it yet), but the type you give for hmap looks unlikely. Did you mean > > > > hmap :: (g :-> h) -> f g :-> f h ? > > > > On Mar 24, 2015 10:58 AM, "Erik Hesselink" wrote: > >> > >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck > >> wrote: > >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: > >> >> There are a good number of different packages that define either > >> >> > >> >> newtype Fix f = Fix (f (Fix f)) > >> >> > >> >> or something equivalent except for naming. Most of the name variation > >> >> is in the name of the data constructor and/or record selector. This > >> >> does not look like an ideal situation to me. Most problematically, > the > >> >> only way to convert one to another is with unsafeCoerce. > >> >> > >> >> I think it would be rather nice to choose one canonical place for > this > >> >> definition, and let everyone else use it. > >> > > >> > +1 > >> > > >> > I propose > >> > > >> > module Data.Fix where > >> > > >> > newtype Fix f = Fix { unFix :: f (Fix f) } > >> > >> I'm used to > >> > >> newtype Fix f = In { out : f (Fix f) } > >> > >> But all the other suggestions look fine to me, too. > >> > >> I've also often used this variation: > >> > >> newtype HFix f a = In { out :: f (HFix f) a } > >> > >> This allows you to take the fixed point of e.g. monad stacks and > >> indexed types. The function you propose below can then be a type class > >> function of an indexed Functor class: > >> > >> type f :-> g = forall a. f a -> g a > >> > >> class HFunctor f where > >> hmap :: (a :-> b) -> f a :-> g a > >> > >> Does this deserve a place somewhere as well? Or is it too specialized? > >> > >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> > Fix f > >> > -> Fix g there. > >> > >> Some variation of 'map' seems sensible, like 'hmap' (but see above) or > >> 'mapFix'. > >> > >> Erik > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Tue Mar 24 16:28:38 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 24 Mar 2015 17:28:38 +0100 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: That seems slightly different, more related to indexed monads with pre- and postconditions. They have many more type variables... Erik On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles wrote: > Higher order stuff is very useful, but I don't think it needs to belong in > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library will > probably deal with this, when we have a GHC that's smart enough to > understand it ;) > > - Ollie > > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink wrote: >> >> Ugh, you're right, I renamed the variables and made a mistake. The >> outer variable should stay the same of course, your signature is >> correct. >> >> For a use site of HFix, see the multirec package [0], although that >> might not really clarify things :) We also have a use internally, but >> I just realized we can probably simplify that away. >> >> Regards, >> >> Erik >> >> [0] >> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >> wrote: >> > I have no comment on your higher-order version (because I don't >> > understand >> > it yet), but the type you give for hmap looks unlikely. Did you mean >> > >> > hmap :: (g :-> h) -> f g :-> f h ? >> > >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" wrote: >> >> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck >> >> wrote: >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >> >> >> There are a good number of different packages that define either >> >> >> >> >> >> newtype Fix f = Fix (f (Fix f)) >> >> >> >> >> >> or something equivalent except for naming. Most of the name >> >> >> variation >> >> >> is in the name of the data constructor and/or record selector. This >> >> >> does not look like an ideal situation to me. Most problematically, >> >> >> the >> >> >> only way to convert one to another is with unsafeCoerce. >> >> >> >> >> >> I think it would be rather nice to choose one canonical place for >> >> >> this >> >> >> definition, and let everyone else use it. >> >> > >> >> > +1 >> >> > >> >> > I propose >> >> > >> >> > module Data.Fix where >> >> > >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >> >> >> >> I'm used to >> >> >> >> newtype Fix f = In { out : f (Fix f) } >> >> >> >> But all the other suggestions look fine to me, too. >> >> >> >> I've also often used this variation: >> >> >> >> newtype HFix f a = In { out :: f (HFix f) a } >> >> >> >> This allows you to take the fixed point of e.g. monad stacks and >> >> indexed types. The function you propose below can then be a type class >> >> function of an indexed Functor class: >> >> >> >> type f :-> g = forall a. f a -> g a >> >> >> >> class HFunctor f where >> >> hmap :: (a :-> b) -> f a :-> g a >> >> >> >> Does this deserve a place somewhere as well? Or is it too specialized? >> >> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> >> >> > Fix f >> >> > -> Fix g there. >> >> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above) or >> >> 'mapFix'. >> >> >> >> Erik >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > From ollie at ocharles.org.uk Tue Mar 24 17:00:15 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Tue, 24 Mar 2015 17:00:15 +0000 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: Oh, I see your confusion - you're looking at `indexed` on Hackage, but I meant the unreleased library on Github. That uses the slice category presentation of higher-order monads/functors, which is what you're talking about: https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 Though HFix isn't there, but I feel it would be a suitable addition to the library. It is unfortunate that there is a name conflict. On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink wrote: > That seems slightly different, more related to indexed monads with > pre- and postconditions. They have many more type variables... > > Erik > > On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles > wrote: > > Higher order stuff is very useful, but I don't think it needs to belong > in > > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library will > > probably deal with this, when we have a GHC that's smart enough to > > understand it ;) > > > > - Ollie > > > > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink > wrote: > >> > >> Ugh, you're right, I renamed the variables and made a mistake. The > >> outer variable should stay the same of course, your signature is > >> correct. > >> > >> For a use site of HFix, see the multirec package [0], although that > >> might not really clarify things :) We also have a use internally, but > >> I just realized we can probably simplify that away. > >> > >> Regards, > >> > >> Erik > >> > >> [0] > >> > http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html > >> > >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer > >> wrote: > >> > I have no comment on your higher-order version (because I don't > >> > understand > >> > it yet), but the type you give for hmap looks unlikely. Did you mean > >> > > >> > hmap :: (g :-> h) -> f g :-> f h ? > >> > > >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" > wrote: > >> >> > >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck > >> >> wrote: > >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: > >> >> >> There are a good number of different packages that define either > >> >> >> > >> >> >> newtype Fix f = Fix (f (Fix f)) > >> >> >> > >> >> >> or something equivalent except for naming. Most of the name > >> >> >> variation > >> >> >> is in the name of the data constructor and/or record selector. > This > >> >> >> does not look like an ideal situation to me. Most problematically, > >> >> >> the > >> >> >> only way to convert one to another is with unsafeCoerce. > >> >> >> > >> >> >> I think it would be rather nice to choose one canonical place for > >> >> >> this > >> >> >> definition, and let everyone else use it. > >> >> > > >> >> > +1 > >> >> > > >> >> > I propose > >> >> > > >> >> > module Data.Fix where > >> >> > > >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } > >> >> > >> >> I'm used to > >> >> > >> >> newtype Fix f = In { out : f (Fix f) } > >> >> > >> >> But all the other suggestions look fine to me, too. > >> >> > >> >> I've also often used this variation: > >> >> > >> >> newtype HFix f a = In { out :: f (HFix f) a } > >> >> > >> >> This allows you to take the fixed point of e.g. monad stacks and > >> >> indexed types. The function you propose below can then be a type > class > >> >> function of an indexed Functor class: > >> >> > >> >> type f :-> g = forall a. f a -> g a > >> >> > >> >> class HFunctor f where > >> >> hmap :: (a :-> b) -> f a :-> g a > >> >> > >> >> Does this deserve a place somewhere as well? Or is it too > specialized? > >> >> > >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> > >> >> > Fix f > >> >> > -> Fix g there. > >> >> > >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above) > or > >> >> 'mapFix'. > >> >> > >> >> Erik > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apfelmus at quantentunnel.de Tue Mar 24 17:11:17 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue, 24 Mar 2015 18:11:17 +0100 Subject: wither the Platform In-Reply-To: <1427149483.11324.447.camel@dunky.localdomain> References: <87h9tdpder.fsf@gnu.org> <1427149483.11324.447.camel@dunky.localdomain> Message-ID: Duncan Coutts wrote: > > As far as I can see there's no conflict between the advocates of mini > and maxi installers (as aimed at new users) except for this behaviour of > new sandboxes. > > All we need to do is make "cabal sandbox init" start with a minimal > package set, rather than taking the global package db. > > It's true that the ghc/platform installers could help with this, e.g. by > shipping an environment file (a new 7.10 feature) that lists all the > core packages, and cabal-install could use this as a basis for new > sandboxes. It would be nice if trying to install a package in the sandbox that is already present in the platform would result in a binary copy rather than a new compilation. But this is just a small optimization. Personally, I like to use a sandbox for every project to get a stable set of dependencies -- I often don't use a .cabal file for on/off projects. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From hesselink at gmail.com Tue Mar 24 17:11:27 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 24 Mar 2015 18:11:27 +0100 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: Ah, thanks. That was confusing indeed, especially since the package on hackage says "Author: Edward A. Kmett" as well. The unreleased library does look like a good place for HFix (IFix). Erik On Tue, Mar 24, 2015 at 6:00 PM, Oliver Charles wrote: > Oh, I see your confusion - you're looking at `indexed` on Hackage, but I > meant the unreleased library on Github. That uses the slice category > presentation of higher-order monads/functors, which is what you're talking > about: > > https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 > > Though HFix isn't there, but I feel it would be a suitable addition to the > library. > > It is unfortunate that there is a name conflict. > > On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink wrote: >> >> That seems slightly different, more related to indexed monads with >> pre- and postconditions. They have many more type variables... >> >> Erik >> >> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles >> wrote: >> > Higher order stuff is very useful, but I don't think it needs to belong >> > in >> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library >> > will >> > probably deal with this, when we have a GHC that's smart enough to >> > understand it ;) >> > >> > - Ollie >> > >> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink >> > wrote: >> >> >> >> Ugh, you're right, I renamed the variables and made a mistake. The >> >> outer variable should stay the same of course, your signature is >> >> correct. >> >> >> >> For a use site of HFix, see the multirec package [0], although that >> >> might not really clarify things :) We also have a use internally, but >> >> I just realized we can probably simplify that away. >> >> >> >> Regards, >> >> >> >> Erik >> >> >> >> [0] >> >> >> >> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >> >> >> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >> >> wrote: >> >> > I have no comment on your higher-order version (because I don't >> >> > understand >> >> > it yet), but the type you give for hmap looks unlikely. Did you mean >> >> > >> >> > hmap :: (g :-> h) -> f g :-> f h ? >> >> > >> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >> >> > wrote: >> >> >> >> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck >> >> >> wrote: >> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >> >> >> >> There are a good number of different packages that define either >> >> >> >> >> >> >> >> newtype Fix f = Fix (f (Fix f)) >> >> >> >> >> >> >> >> or something equivalent except for naming. Most of the name >> >> >> >> variation >> >> >> >> is in the name of the data constructor and/or record selector. >> >> >> >> This >> >> >> >> does not look like an ideal situation to me. Most >> >> >> >> problematically, >> >> >> >> the >> >> >> >> only way to convert one to another is with unsafeCoerce. >> >> >> >> >> >> >> >> I think it would be rather nice to choose one canonical place for >> >> >> >> this >> >> >> >> definition, and let everyone else use it. >> >> >> > >> >> >> > +1 >> >> >> > >> >> >> > I propose >> >> >> > >> >> >> > module Data.Fix where >> >> >> > >> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >> >> >> >> >> >> I'm used to >> >> >> >> >> >> newtype Fix f = In { out : f (Fix f) } >> >> >> >> >> >> But all the other suggestions look fine to me, too. >> >> >> >> >> >> I've also often used this variation: >> >> >> >> >> >> newtype HFix f a = In { out :: f (HFix f) a } >> >> >> >> >> >> This allows you to take the fixed point of e.g. monad stacks and >> >> >> indexed types. The function you propose below can then be a type >> >> >> class >> >> >> function of an indexed Functor class: >> >> >> >> >> >> type f :-> g = forall a. f a -> g a >> >> >> >> >> >> class HFunctor f where >> >> >> hmap :: (a :-> b) -> f a :-> g a >> >> >> >> >> >> Does this deserve a place somewhere as well? Or is it too >> >> >> specialized? >> >> >> >> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> >> >> >> > Fix f >> >> >> > -> Fix g there. >> >> >> >> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above) >> >> >> or >> >> >> 'mapFix'. >> >> >> >> >> >> Erik >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> > > > From vishal4556 at gmail.com Tue Mar 24 17:23:12 2015 From: vishal4556 at gmail.com (Vishal Agrawal) Date: Tue, 24 Mar 2015 22:53:12 +0530 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: Message-ID: I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. Can you review the proposal and give me suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 24 18:25:21 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 24 Mar 2015 14:25:21 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: History of indexed: The version of indexed on hackage was split out of my old category-extras package by Reiner Pope. I asked a couple of years back if I could replace it with a new version, and he said yes. The version on my github is my exploration of that design space. It was stalled because of issues with GHC circa 7.6. Notably: Any inhabiting every kind meant that it wasn't sound to assume that the only inhabitants of the product kind (i,j) are of the form '(a, b) for a :: i, and b :: j. We've fixed most of those issues in GHC 7.10, so in theory i could pick up my indexed package and finish it. There are other issues still outstanding, but that was the big one. I think there are enough points in this design space that I'm much much happier to have this sort of thing in libraries that are removed from base than having it in base itself. As an example: Making useful instances for it requires either UndecidableInstances or switching to something like Data.Functor.Classes or the machinery prelude-extras. I'm not terribly comfortable with base making a bet on one such horse at the expense of the others, and I'm even less comfortable moving the data type up where any such instances would perforce be orphans if we didn't supply them. *tl;dr* -1 -Edward On Tue, Mar 24, 2015 at 1:00 PM, Oliver Charles wrote: > Oh, I see your confusion - you're looking at `indexed` on Hackage, but I > meant the unreleased library on Github. That uses the slice category > presentation of higher-order monads/functors, which is what you're talking > about: > > https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 > > Though HFix isn't there, but I feel it would be a suitable addition to the > library. > > It is unfortunate that there is a name conflict. > > On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink > wrote: > >> That seems slightly different, more related to indexed monads with >> pre- and postconditions. They have many more type variables... >> >> Erik >> >> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles >> wrote: >> > Higher order stuff is very useful, but I don't think it needs to belong >> in >> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library >> will >> > probably deal with this, when we have a GHC that's smart enough to >> > understand it ;) >> > >> > - Ollie >> > >> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink >> wrote: >> >> >> >> Ugh, you're right, I renamed the variables and made a mistake. The >> >> outer variable should stay the same of course, your signature is >> >> correct. >> >> >> >> For a use site of HFix, see the multirec package [0], although that >> >> might not really clarify things :) We also have a use internally, but >> >> I just realized we can probably simplify that away. >> >> >> >> Regards, >> >> >> >> Erik >> >> >> >> [0] >> >> >> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >> >> >> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >> >> wrote: >> >> > I have no comment on your higher-order version (because I don't >> >> > understand >> >> > it yet), but the type you give for hmap looks unlikely. Did you mean >> >> > >> >> > hmap :: (g :-> h) -> f g :-> f h ? >> >> > >> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >> wrote: >> >> >> >> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck > > >> >> >> wrote: >> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >> >> >> >> There are a good number of different packages that define either >> >> >> >> >> >> >> >> newtype Fix f = Fix (f (Fix f)) >> >> >> >> >> >> >> >> or something equivalent except for naming. Most of the name >> >> >> >> variation >> >> >> >> is in the name of the data constructor and/or record selector. >> This >> >> >> >> does not look like an ideal situation to me. Most >> problematically, >> >> >> >> the >> >> >> >> only way to convert one to another is with unsafeCoerce. >> >> >> >> >> >> >> >> I think it would be rather nice to choose one canonical place for >> >> >> >> this >> >> >> >> definition, and let everyone else use it. >> >> >> > >> >> >> > +1 >> >> >> > >> >> >> > I propose >> >> >> > >> >> >> > module Data.Fix where >> >> >> > >> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >> >> >> >> >> >> I'm used to >> >> >> >> >> >> newtype Fix f = In { out : f (Fix f) } >> >> >> >> >> >> But all the other suggestions look fine to me, too. >> >> >> >> >> >> I've also often used this variation: >> >> >> >> >> >> newtype HFix f a = In { out :: f (HFix f) a } >> >> >> >> >> >> This allows you to take the fixed point of e.g. monad stacks and >> >> >> indexed types. The function you propose below can then be a type >> class >> >> >> function of an indexed Functor class: >> >> >> >> >> >> type f :-> g = forall a. f a -> g a >> >> >> >> >> >> class HFunctor f where >> >> >> hmap :: (a :-> b) -> f a :-> g a >> >> >> >> >> >> Does this deserve a place somewhere as well? Or is it too >> specialized? >> >> >> >> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) -> >> >> >> > Fix f >> >> >> > -> Fix g there. >> >> >> >> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above) >> or >> >> >> 'mapFix'. >> >> >> >> >> >> Erik >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> > >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 24 18:41:34 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 24 Mar 2015 14:41:34 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: I don't understand what you're getting at, Edward. The specific type I mentioned, newtype Fix f = Fix (f (Fix f)), seems to be defined and used in various places. Are there important differences in the instances *for that type*? Or are you concerned about the higher-order versions? I'm also not at all committed to putting this in base, per se. I just don't like the fact that various unrelated packages with very different purposes are all doing the same thing, and that these identical types cannot be used together. On Mar 24, 2015 2:25 PM, "Edward Kmett" wrote: > History of indexed: > > The version of indexed on hackage was split out of my old category-extras > package by Reiner Pope. I asked a couple of years back if I could replace > it with a new version, and he said yes. > > The version on my github is my exploration of that design space. It was > stalled because of issues with GHC circa 7.6. Notably: Any inhabiting every > kind meant that it wasn't sound to assume that the only inhabitants of the > product kind (i,j) are of the form '(a, b) for a :: i, and b :: j. We've > fixed most of those issues in GHC 7.10, so in theory i could pick up my > indexed package and finish it. There are other issues still outstanding, > but that was the big one. > > I think there are enough points in this design space that I'm much much > happier to have this sort of thing in libraries that are removed from base > than having it in base itself. As an example: Making useful instances for > it requires either UndecidableInstances or switching to something like > Data.Functor.Classes or the machinery prelude-extras. I'm not terribly > comfortable with base making a bet on one such horse at the expense of the > others, and I'm even less comfortable moving the data type up where any > such instances would perforce be orphans if we didn't supply them. > > *tl;dr* -1 > > -Edward > > > On Tue, Mar 24, 2015 at 1:00 PM, Oliver Charles > wrote: > >> Oh, I see your confusion - you're looking at `indexed` on Hackage, but I >> meant the unreleased library on Github. That uses the slice category >> presentation of higher-order monads/functors, which is what you're talking >> about: >> >> https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 >> >> Though HFix isn't there, but I feel it would be a suitable addition to >> the library. >> >> It is unfortunate that there is a name conflict. >> >> On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink >> wrote: >> >>> That seems slightly different, more related to indexed monads with >>> pre- and postconditions. They have many more type variables... >>> >>> Erik >>> >>> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles >>> wrote: >>> > Higher order stuff is very useful, but I don't think it needs to >>> belong in >>> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library >>> will >>> > probably deal with this, when we have a GHC that's smart enough to >>> > understand it ;) >>> > >>> > - Ollie >>> > >>> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink >>> wrote: >>> >> >>> >> Ugh, you're right, I renamed the variables and made a mistake. The >>> >> outer variable should stay the same of course, your signature is >>> >> correct. >>> >> >>> >> For a use site of HFix, see the multirec package [0], although that >>> >> might not really clarify things :) We also have a use internally, but >>> >> I just realized we can probably simplify that away. >>> >> >>> >> Regards, >>> >> >>> >> Erik >>> >> >>> >> [0] >>> >> >>> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >>> >> >>> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >>> >> wrote: >>> >> > I have no comment on your higher-order version (because I don't >>> >> > understand >>> >> > it yet), but the type you give for hmap looks unlikely. Did you mean >>> >> > >>> >> > hmap :: (g :-> h) -> f g :-> f h ? >>> >> > >>> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >>> wrote: >>> >> >> >>> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck < >>> strake888 at gmail.com> >>> >> >> wrote: >>> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >>> >> >> >> There are a good number of different packages that define either >>> >> >> >> >>> >> >> >> newtype Fix f = Fix (f (Fix f)) >>> >> >> >> >>> >> >> >> or something equivalent except for naming. Most of the name >>> >> >> >> variation >>> >> >> >> is in the name of the data constructor and/or record selector. >>> This >>> >> >> >> does not look like an ideal situation to me. Most >>> problematically, >>> >> >> >> the >>> >> >> >> only way to convert one to another is with unsafeCoerce. >>> >> >> >> >>> >> >> >> I think it would be rather nice to choose one canonical place >>> for >>> >> >> >> this >>> >> >> >> definition, and let everyone else use it. >>> >> >> > >>> >> >> > +1 >>> >> >> > >>> >> >> > I propose >>> >> >> > >>> >> >> > module Data.Fix where >>> >> >> > >>> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >>> >> >> >>> >> >> I'm used to >>> >> >> >>> >> >> newtype Fix f = In { out : f (Fix f) } >>> >> >> >>> >> >> But all the other suggestions look fine to me, too. >>> >> >> >>> >> >> I've also often used this variation: >>> >> >> >>> >> >> newtype HFix f a = In { out :: f (HFix f) a } >>> >> >> >>> >> >> This allows you to take the fixed point of e.g. monad stacks and >>> >> >> indexed types. The function you propose below can then be a type >>> class >>> >> >> function of an indexed Functor class: >>> >> >> >>> >> >> type f :-> g = forall a. f a -> g a >>> >> >> >>> >> >> class HFunctor f where >>> >> >> hmap :: (a :-> b) -> f a :-> g a >>> >> >> >>> >> >> Does this deserve a place somewhere as well? Or is it too >>> specialized? >>> >> >> >>> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) >>> -> >>> >> >> > Fix f >>> >> >> > -> Fix g there. >>> >> >> >>> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see >>> above) or >>> >> >> 'mapFix'. >>> >> >> >>> >> >> Erik >>> >> _______________________________________________ >>> >> Libraries mailing list >>> >> Libraries at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> > >>> > >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 24 18:59:06 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 24 Mar 2015 14:59:06 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: For that version. There are two viable definitions for Show instance Show1 f => Show (Fix f) instance Show (f (Fix f)) => Show (Fix f) Similarly for Eq, Ord, Read. The former is the style used in transformers 0.4+ adapted from what I did in prelude-extras. The latter is the style we had to use before, but which relies on UndecidableInstances and FlexibleContexts. -Edward On Tue, Mar 24, 2015 at 2:41 PM, David Feuer wrote: > I don't understand what you're getting at, Edward. The specific type I > mentioned, newtype Fix f = Fix (f (Fix f)), seems to be defined and used in > various places. Are there important differences in the instances *for that > type*? Or are you concerned about the higher-order versions? > > I'm also not at all committed to putting this in base, per se. I just > don't like the fact that various unrelated packages with very different > purposes are all doing the same thing, and that these identical types > cannot be used together. > On Mar 24, 2015 2:25 PM, "Edward Kmett" wrote: > >> History of indexed: >> >> The version of indexed on hackage was split out of my old category-extras >> package by Reiner Pope. I asked a couple of years back if I could replace >> it with a new version, and he said yes. >> >> The version on my github is my exploration of that design space. It was >> stalled because of issues with GHC circa 7.6. Notably: Any inhabiting every >> kind meant that it wasn't sound to assume that the only inhabitants of the >> product kind (i,j) are of the form '(a, b) for a :: i, and b :: j. We've >> fixed most of those issues in GHC 7.10, so in theory i could pick up my >> indexed package and finish it. There are other issues still outstanding, >> but that was the big one. >> >> I think there are enough points in this design space that I'm much much >> happier to have this sort of thing in libraries that are removed from base >> than having it in base itself. As an example: Making useful instances for >> it requires either UndecidableInstances or switching to something like >> Data.Functor.Classes or the machinery prelude-extras. I'm not terribly >> comfortable with base making a bet on one such horse at the expense of the >> others, and I'm even less comfortable moving the data type up where any >> such instances would perforce be orphans if we didn't supply them. >> >> *tl;dr* -1 >> >> -Edward >> >> >> On Tue, Mar 24, 2015 at 1:00 PM, Oliver Charles >> wrote: >> >>> Oh, I see your confusion - you're looking at `indexed` on Hackage, but I >>> meant the unreleased library on Github. That uses the slice category >>> presentation of higher-order monads/functors, which is what you're talking >>> about: >>> >>> https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 >>> >>> Though HFix isn't there, but I feel it would be a suitable addition to >>> the library. >>> >>> It is unfortunate that there is a name conflict. >>> >>> On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink >>> wrote: >>> >>>> That seems slightly different, more related to indexed monads with >>>> pre- and postconditions. They have many more type variables... >>>> >>>> Erik >>>> >>>> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles >>>> wrote: >>>> > Higher order stuff is very useful, but I don't think it needs to >>>> belong in >>>> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library >>>> will >>>> > probably deal with this, when we have a GHC that's smart enough to >>>> > understand it ;) >>>> > >>>> > - Ollie >>>> > >>>> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink >>>> wrote: >>>> >> >>>> >> Ugh, you're right, I renamed the variables and made a mistake. The >>>> >> outer variable should stay the same of course, your signature is >>>> >> correct. >>>> >> >>>> >> For a use site of HFix, see the multirec package [0], although that >>>> >> might not really clarify things :) We also have a use internally, but >>>> >> I just realized we can probably simplify that away. >>>> >> >>>> >> Regards, >>>> >> >>>> >> Erik >>>> >> >>>> >> [0] >>>> >> >>>> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >>>> >> >>>> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >>>> >> wrote: >>>> >> > I have no comment on your higher-order version (because I don't >>>> >> > understand >>>> >> > it yet), but the type you give for hmap looks unlikely. Did you >>>> mean >>>> >> > >>>> >> > hmap :: (g :-> h) -> f g :-> f h ? >>>> >> > >>>> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >>>> wrote: >>>> >> >> >>>> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck < >>>> strake888 at gmail.com> >>>> >> >> wrote: >>>> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >>>> >> >> >> There are a good number of different packages that define >>>> either >>>> >> >> >> >>>> >> >> >> newtype Fix f = Fix (f (Fix f)) >>>> >> >> >> >>>> >> >> >> or something equivalent except for naming. Most of the name >>>> >> >> >> variation >>>> >> >> >> is in the name of the data constructor and/or record selector. >>>> This >>>> >> >> >> does not look like an ideal situation to me. Most >>>> problematically, >>>> >> >> >> the >>>> >> >> >> only way to convert one to another is with unsafeCoerce. >>>> >> >> >> >>>> >> >> >> I think it would be rather nice to choose one canonical place >>>> for >>>> >> >> >> this >>>> >> >> >> definition, and let everyone else use it. >>>> >> >> > >>>> >> >> > +1 >>>> >> >> > >>>> >> >> > I propose >>>> >> >> > >>>> >> >> > module Data.Fix where >>>> >> >> > >>>> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >>>> >> >> >>>> >> >> I'm used to >>>> >> >> >>>> >> >> newtype Fix f = In { out : f (Fix f) } >>>> >> >> >>>> >> >> But all the other suggestions look fine to me, too. >>>> >> >> >>>> >> >> I've also often used this variation: >>>> >> >> >>>> >> >> newtype HFix f a = In { out :: f (HFix f) a } >>>> >> >> >>>> >> >> This allows you to take the fixed point of e.g. monad stacks and >>>> >> >> indexed types. The function you propose below can then be a type >>>> class >>>> >> >> function of an indexed Functor class: >>>> >> >> >>>> >> >> type f :-> g = forall a. f a -> g a >>>> >> >> >>>> >> >> class HFunctor f where >>>> >> >> hmap :: (a :-> b) -> f a :-> g a >>>> >> >> >>>> >> >> Does this deserve a place somewhere as well? Or is it too >>>> specialized? >>>> >> >> >>>> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g a) >>>> -> >>>> >> >> > Fix f >>>> >> >> > -> Fix g there. >>>> >> >> >>>> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see >>>> above) or >>>> >> >> 'mapFix'. >>>> >> >> >>>> >> >> Erik >>>> >> _______________________________________________ >>>> >> Libraries mailing list >>>> >> Libraries at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> > >>>> > >>>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Mar 24 19:18:39 2015 From: david.feuer at gmail.com (David Feuer) Date: Tue, 24 Mar 2015 15:18:39 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: I'm not saying that we need to find the One True Way, and none of it needs to go in base (at least for now). I just think it would be better to have several different versions in one place (transformers, or some special package just for this, or whatever) than to have things like XML libraries defining their own. On Mar 24, 2015 2:59 PM, "Edward Kmett" wrote: > For that version. > > There are two viable definitions for Show > > instance Show1 f => Show (Fix f) > > instance Show (f (Fix f)) => Show (Fix f) > > Similarly for Eq, Ord, Read. > > The former is the style used in transformers 0.4+ adapted from what I did > in prelude-extras. > > The latter is the style we had to use before, but which relies on > UndecidableInstances and FlexibleContexts. > > -Edward > > On Tue, Mar 24, 2015 at 2:41 PM, David Feuer > wrote: > >> I don't understand what you're getting at, Edward. The specific type I >> mentioned, newtype Fix f = Fix (f (Fix f)), seems to be defined and used in >> various places. Are there important differences in the instances *for that >> type*? Or are you concerned about the higher-order versions? >> >> I'm also not at all committed to putting this in base, per se. I just >> don't like the fact that various unrelated packages with very different >> purposes are all doing the same thing, and that these identical types >> cannot be used together. >> On Mar 24, 2015 2:25 PM, "Edward Kmett" wrote: >> >>> History of indexed: >>> >>> The version of indexed on hackage was split out of my old >>> category-extras package by Reiner Pope. I asked a couple of years back if I >>> could replace it with a new version, and he said yes. >>> >>> The version on my github is my exploration of that design space. It was >>> stalled because of issues with GHC circa 7.6. Notably: Any inhabiting every >>> kind meant that it wasn't sound to assume that the only inhabitants of the >>> product kind (i,j) are of the form '(a, b) for a :: i, and b :: j. We've >>> fixed most of those issues in GHC 7.10, so in theory i could pick up my >>> indexed package and finish it. There are other issues still outstanding, >>> but that was the big one. >>> >>> I think there are enough points in this design space that I'm much much >>> happier to have this sort of thing in libraries that are removed from base >>> than having it in base itself. As an example: Making useful instances for >>> it requires either UndecidableInstances or switching to something like >>> Data.Functor.Classes or the machinery prelude-extras. I'm not terribly >>> comfortable with base making a bet on one such horse at the expense of the >>> others, and I'm even less comfortable moving the data type up where any >>> such instances would perforce be orphans if we didn't supply them. >>> >>> *tl;dr* -1 >>> >>> -Edward >>> >>> >>> On Tue, Mar 24, 2015 at 1:00 PM, Oliver Charles >>> wrote: >>> >>>> Oh, I see your confusion - you're looking at `indexed` on Hackage, but >>>> I meant the unreleased library on Github. That uses the slice category >>>> presentation of higher-order monads/functors, which is what you're talking >>>> about: >>>> >>>> https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 >>>> >>>> Though HFix isn't there, but I feel it would be a suitable addition to >>>> the library. >>>> >>>> It is unfortunate that there is a name conflict. >>>> >>>> On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink >>>> wrote: >>>> >>>>> That seems slightly different, more related to indexed monads with >>>>> pre- and postconditions. They have many more type variables... >>>>> >>>>> Erik >>>>> >>>>> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles >>>>> wrote: >>>>> > Higher order stuff is very useful, but I don't think it needs to >>>>> belong in >>>>> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library >>>>> will >>>>> > probably deal with this, when we have a GHC that's smart enough to >>>>> > understand it ;) >>>>> > >>>>> > - Ollie >>>>> > >>>>> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink >>>>> wrote: >>>>> >> >>>>> >> Ugh, you're right, I renamed the variables and made a mistake. The >>>>> >> outer variable should stay the same of course, your signature is >>>>> >> correct. >>>>> >> >>>>> >> For a use site of HFix, see the multirec package [0], although that >>>>> >> might not really clarify things :) We also have a use internally, >>>>> but >>>>> >> I just realized we can probably simplify that away. >>>>> >> >>>>> >> Regards, >>>>> >> >>>>> >> Erik >>>>> >> >>>>> >> [0] >>>>> >> >>>>> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >>>>> >> >>>>> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer >>>> > >>>>> >> wrote: >>>>> >> > I have no comment on your higher-order version (because I don't >>>>> >> > understand >>>>> >> > it yet), but the type you give for hmap looks unlikely. Did you >>>>> mean >>>>> >> > >>>>> >> > hmap :: (g :-> h) -> f g :-> f h ? >>>>> >> > >>>>> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >>>>> wrote: >>>>> >> >> >>>>> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck < >>>>> strake888 at gmail.com> >>>>> >> >> wrote: >>>>> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >>>>> >> >> >> There are a good number of different packages that define >>>>> either >>>>> >> >> >> >>>>> >> >> >> newtype Fix f = Fix (f (Fix f)) >>>>> >> >> >> >>>>> >> >> >> or something equivalent except for naming. Most of the name >>>>> >> >> >> variation >>>>> >> >> >> is in the name of the data constructor and/or record >>>>> selector. This >>>>> >> >> >> does not look like an ideal situation to me. Most >>>>> problematically, >>>>> >> >> >> the >>>>> >> >> >> only way to convert one to another is with unsafeCoerce. >>>>> >> >> >> >>>>> >> >> >> I think it would be rather nice to choose one canonical place >>>>> for >>>>> >> >> >> this >>>>> >> >> >> definition, and let everyone else use it. >>>>> >> >> > >>>>> >> >> > +1 >>>>> >> >> > >>>>> >> >> > I propose >>>>> >> >> > >>>>> >> >> > module Data.Fix where >>>>> >> >> > >>>>> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >>>>> >> >> >>>>> >> >> I'm used to >>>>> >> >> >>>>> >> >> newtype Fix f = In { out : f (Fix f) } >>>>> >> >> >>>>> >> >> But all the other suggestions look fine to me, too. >>>>> >> >> >>>>> >> >> I've also often used this variation: >>>>> >> >> >>>>> >> >> newtype HFix f a = In { out :: f (HFix f) a } >>>>> >> >> >>>>> >> >> This allows you to take the fixed point of e.g. monad stacks and >>>>> >> >> indexed types. The function you propose below can then be a type >>>>> class >>>>> >> >> function of an indexed Functor class: >>>>> >> >> >>>>> >> >> type f :-> g = forall a. f a -> g a >>>>> >> >> >>>>> >> >> class HFunctor f where >>>>> >> >> hmap :: (a :-> b) -> f a :-> g a >>>>> >> >> >>>>> >> >> Does this deserve a place somewhere as well? Or is it too >>>>> specialized? >>>>> >> >> >>>>> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g >>>>> a) -> >>>>> >> >> > Fix f >>>>> >> >> > -> Fix g there. >>>>> >> >> >>>>> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see >>>>> above) or >>>>> >> >> 'mapFix'. >>>>> >> >> >>>>> >> >> Erik >>>>> >> _______________________________________________ >>>>> >> Libraries mailing list >>>>> >> Libraries at haskell.org >>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> > >>>>> > >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.tetley at gmail.com Tue Mar 24 20:08:18 2015 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Tue, 24 Mar 2015 20:08:18 +0000 Subject: wither the Platform In-Reply-To: <1427206788567-5767542.post@n5.nabble.com> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> <1427206788567-5767542.post@n5.nabble.com> Message-ID: Because then you are working with a unique snapshot rather than one in communal use. Writing code to work with the Platform is "social gesture" that gives some hint that your code works for others. On 24 March 2015 at 14:19, Jeremy wrote: > Jeremy O'Donoghue wrote >> 1) Code I write needs to run on Mac (where it is written), Windows and >> Linux (where it is usually used). None of the 'build it yourself' >> alternatives gives a way to ensure, with confidence, that I have the same >> platform on each of my machines. > > Why not just install GHC x.y.z and cabal freeze? (You could also use a > stackage snapshot.) > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767542.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From ekmett at gmail.com Tue Mar 24 20:16:06 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 24 Mar 2015 16:16:06 -0400 Subject: Fixing Fix In-Reply-To: References: <20150324062344.GA1832@mintha> Message-ID: FWIW- My http://hackage.haskell.org/package/recursion-schemes package supplies all 3 of the standard encodings and showcases the mappings between them. -Edward On Tue, Mar 24, 2015 at 3:18 PM, David Feuer wrote: > I'm not saying that we need to find the One True Way, and none of it needs > to go in base (at least for now). I just think it would be better to have > several different versions in one place (transformers, or some special > package just for this, or whatever) than to have things like XML libraries > defining their own. > On Mar 24, 2015 2:59 PM, "Edward Kmett" wrote: > >> For that version. >> >> There are two viable definitions for Show >> >> instance Show1 f => Show (Fix f) >> >> instance Show (f (Fix f)) => Show (Fix f) >> >> Similarly for Eq, Ord, Read. >> >> The former is the style used in transformers 0.4+ adapted from what I did >> in prelude-extras. >> >> The latter is the style we had to use before, but which relies on >> UndecidableInstances and FlexibleContexts. >> >> -Edward >> >> On Tue, Mar 24, 2015 at 2:41 PM, David Feuer >> wrote: >> >>> I don't understand what you're getting at, Edward. The specific type I >>> mentioned, newtype Fix f = Fix (f (Fix f)), seems to be defined and used in >>> various places. Are there important differences in the instances *for that >>> type*? Or are you concerned about the higher-order versions? >>> >>> I'm also not at all committed to putting this in base, per se. I just >>> don't like the fact that various unrelated packages with very different >>> purposes are all doing the same thing, and that these identical types >>> cannot be used together. >>> On Mar 24, 2015 2:25 PM, "Edward Kmett" wrote: >>> >>>> History of indexed: >>>> >>>> The version of indexed on hackage was split out of my old >>>> category-extras package by Reiner Pope. I asked a couple of years back if I >>>> could replace it with a new version, and he said yes. >>>> >>>> The version on my github is my exploration of that design space. It was >>>> stalled because of issues with GHC circa 7.6. Notably: Any inhabiting every >>>> kind meant that it wasn't sound to assume that the only inhabitants of the >>>> product kind (i,j) are of the form '(a, b) for a :: i, and b :: j. We've >>>> fixed most of those issues in GHC 7.10, so in theory i could pick up my >>>> indexed package and finish it. There are other issues still outstanding, >>>> but that was the big one. >>>> >>>> I think there are enough points in this design space that I'm much much >>>> happier to have this sort of thing in libraries that are removed from base >>>> than having it in base itself. As an example: Making useful instances for >>>> it requires either UndecidableInstances or switching to something like >>>> Data.Functor.Classes or the machinery prelude-extras. I'm not terribly >>>> comfortable with base making a bet on one such horse at the expense of the >>>> others, and I'm even less comfortable moving the data type up where any >>>> such instances would perforce be orphans if we didn't supply them. >>>> >>>> *tl;dr* -1 >>>> >>>> -Edward >>>> >>>> >>>> On Tue, Mar 24, 2015 at 1:00 PM, Oliver Charles >>>> wrote: >>>> >>>>> Oh, I see your confusion - you're looking at `indexed` on Hackage, but >>>>> I meant the unreleased library on Github. That uses the slice category >>>>> presentation of higher-order monads/functors, which is what you're talking >>>>> about: >>>>> >>>>> >>>>> https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53 >>>>> >>>>> Though HFix isn't there, but I feel it would be a suitable addition to >>>>> the library. >>>>> >>>>> It is unfortunate that there is a name conflict. >>>>> >>>>> On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink >>>>> wrote: >>>>> >>>>>> That seems slightly different, more related to indexed monads with >>>>>> pre- and postconditions. They have many more type variables... >>>>>> >>>>>> Erik >>>>>> >>>>>> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles < >>>>>> ollie at ocharles.org.uk> wrote: >>>>>> > Higher order stuff is very useful, but I don't think it needs to >>>>>> belong in >>>>>> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' >>>>>> library will >>>>>> > probably deal with this, when we have a GHC that's smart enough to >>>>>> > understand it ;) >>>>>> > >>>>>> > - Ollie >>>>>> > >>>>>> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink < >>>>>> hesselink at gmail.com> wrote: >>>>>> >> >>>>>> >> Ugh, you're right, I renamed the variables and made a mistake. The >>>>>> >> outer variable should stay the same of course, your signature is >>>>>> >> correct. >>>>>> >> >>>>>> >> For a use site of HFix, see the multirec package [0], although that >>>>>> >> might not really clarify things :) We also have a use internally, >>>>>> but >>>>>> >> I just realized we can probably simplify that away. >>>>>> >> >>>>>> >> Regards, >>>>>> >> >>>>>> >> Erik >>>>>> >> >>>>>> >> [0] >>>>>> >> >>>>>> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html >>>>>> >> >>>>>> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer < >>>>>> david.feuer at gmail.com> >>>>>> >> wrote: >>>>>> >> > I have no comment on your higher-order version (because I don't >>>>>> >> > understand >>>>>> >> > it yet), but the type you give for hmap looks unlikely. Did you >>>>>> mean >>>>>> >> > >>>>>> >> > hmap :: (g :-> h) -> f g :-> f h ? >>>>>> >> > >>>>>> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" >>>>>> wrote: >>>>>> >> >> >>>>>> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck < >>>>>> strake888 at gmail.com> >>>>>> >> >> wrote: >>>>>> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote: >>>>>> >> >> >> There are a good number of different packages that define >>>>>> either >>>>>> >> >> >> >>>>>> >> >> >> newtype Fix f = Fix (f (Fix f)) >>>>>> >> >> >> >>>>>> >> >> >> or something equivalent except for naming. Most of the name >>>>>> >> >> >> variation >>>>>> >> >> >> is in the name of the data constructor and/or record >>>>>> selector. This >>>>>> >> >> >> does not look like an ideal situation to me. Most >>>>>> problematically, >>>>>> >> >> >> the >>>>>> >> >> >> only way to convert one to another is with unsafeCoerce. >>>>>> >> >> >> >>>>>> >> >> >> I think it would be rather nice to choose one canonical >>>>>> place for >>>>>> >> >> >> this >>>>>> >> >> >> definition, and let everyone else use it. >>>>>> >> >> > >>>>>> >> >> > +1 >>>>>> >> >> > >>>>>> >> >> > I propose >>>>>> >> >> > >>>>>> >> >> > module Data.Fix where >>>>>> >> >> > >>>>>> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) } >>>>>> >> >> >>>>>> >> >> I'm used to >>>>>> >> >> >>>>>> >> >> newtype Fix f = In { out : f (Fix f) } >>>>>> >> >> >>>>>> >> >> But all the other suggestions look fine to me, too. >>>>>> >> >> >>>>>> >> >> I've also often used this variation: >>>>>> >> >> >>>>>> >> >> newtype HFix f a = In { out :: f (HFix f) a } >>>>>> >> >> >>>>>> >> >> This allows you to take the fixed point of e.g. monad stacks and >>>>>> >> >> indexed types. The function you propose below can then be a >>>>>> type class >>>>>> >> >> function of an indexed Functor class: >>>>>> >> >> >>>>>> >> >> type f :-> g = forall a. f a -> g a >>>>>> >> >> >>>>>> >> >> class HFunctor f where >>>>>> >> >> hmap :: (a :-> b) -> f a :-> g a >>>>>> >> >> >>>>>> >> >> Does this deserve a place somewhere as well? Or is it too >>>>>> specialized? >>>>>> >> >> >>>>>> >> >> > Perhaps too we ought to name and define _ :: (? a . f a -> g >>>>>> a) -> >>>>>> >> >> > Fix f >>>>>> >> >> > -> Fix g there. >>>>>> >> >> >>>>>> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see >>>>>> above) or >>>>>> >> >> 'mapFix'. >>>>>> >> >> >>>>>> >> >> Erik >>>>>> >> _______________________________________________ >>>>>> >> Libraries mailing list >>>>>> >> Libraries at haskell.org >>>>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Wed Mar 25 00:13:52 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 11:13:52 +1100 Subject: wither the Platform In-Reply-To: <1427151077.11324.459.camel@dunky.localdomain> References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: > Duncan Coutts : > On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: >> I'm wondering how we are all feeling about the platform these days.... >> >> I notice that in the new Haskell pages, the Platform is definitely not the >> recommended way to go: The main download pages suggests the compiler and >> base libraries as the first option - and the text for the Platform (second >> option) pretty much steers folks away from it. Of the per-OS download >> pages, only the Windows version even mentions it. > > There was a big argument about this. I was on the loosing side. :-) > >> Does this mean that we don't want to consider continuing with it? It is a >> lot of community effort to put out a Platform release - we shouldn't do it >> if we don't really want it. > > I think it is worth it, and the issues that people are complaining about > wrt the platform vs minimal installers can be fixed. > >> That said, I note that the other ways to "officially get" Haskell look, to >> my eye, very ad hoc. Many of the options involve multiple steps, and >> exactly what one is getting isn't clear. It hardly looks like there is now >> an "official, correct" way to setup Haskell. > > Right, I think there's still a great deal of value in having a simple > recommendation for new users. Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users. A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. We are using Haskell in a few courses here at UNSW. We always recommend students to use the Haskell Platform when they want to install Haskell on their own machines. It?s one download and gives them the same packages on all platforms. Anything else just leads to lots of support questions of students trying to get their installations working to do their assignments. Manuel > One of the points of argument was that some people were arguing that the > minimal installers are better for new users. I disagree, but certainly > there is one issue that could be fixed that'd go a long way to resolving > the particular use case with new users that was raised. > >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. > >> I don't think the status quo for the Platform is now viable - mostly as >> evidenced by waning interest in maintaining it. I offer several ways we >> could proceed: > > Well, the people who like it don't really complain. But yes, things need > improving. > >> *1) Abandon the Platform.* GHC is release in source and binary form. Other >> package various installers, with more or less things, for various OSes. >> >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of >> "essential" libs + tools. Keeps a consistent build layout and installation >> mechanism for Haskell. >> >> *3) Re-conceive the Platform.* Take a very minimal install approach, >> coupled with close integration with a curated library set that makes it >> easy to have a rich canonical, stable environment. This was the core idea >> around my "GPS Haskell" thoughts from last September - but there would be >> much to work out in this direction. > > I'm not sure that slimming is really needed. But I agree with the GPS > approach. The current set is too small in the sense that it doesn't > cover lots of things people need, and the GPS approach should solve > that. We don't need to promise such high QA for the extended set, we > just need to make sure they build together. > > We need to remember that one of the purposes of the platform as > originally conceived is to get people to sync on the versions of their > deps that they're using at the moment. This is where the GPS approach > shines, but it still makes sense to have some core set at the middle of > that. It's true that advanced users don't need lots of things > pre-installed, but they sill benefit from other developers synchronising > on versions of deps, so that they can have more things work together > more often. > > On the argument that the platform is too big, the primary issue there is > that people want to make new sandboxes that are more minimal, and with > cabal's current behaviour of basing all sandboxes off of the global > package db, and the platform installing lots of packages globally then > we get a conflict. > > But the solution is simple: make cabal sandboxes not be based off of > everything that is globally installed, make new sandboxes be really > minimal (though the ghc/platform installers could help with identifying > what is the minimal subset). > > Duncan > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Wed Mar 25 00:54:35 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 24 Mar 2015 20:54:35 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: I absolutely agree that haskell platform is the right choice for class rooms. On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" wrote: > > Duncan Coutts : > > On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: > >> I'm wondering how we are all feeling about the platform these days.... > >> > >> I notice that in the new Haskell pages, the Platform is definitely not > the > >> recommended way to go: The main download pages suggests the compiler and > >> base libraries as the first option - and the text for the Platform > (second > >> option) pretty much steers folks away from it. Of the per-OS download > >> pages, only the Windows version even mentions it. > > > > There was a big argument about this. I was on the loosing side. :-) > > > >> Does this mean that we don't want to consider continuing with it? It is > a > >> lot of community effort to put out a Platform release - we shouldn't do > it > >> if we don't really want it. > > > > I think it is worth it, and the issues that people are complaining about > > wrt the platform vs minimal installers can be fixed. > > > >> That said, I note that the other ways to "officially get" Haskell look, > to > >> my eye, very ad hoc. Many of the options involve multiple steps, and > >> exactly what one is getting isn't clear. It hardly looks like there is > now > >> an "official, correct" way to setup Haskell. > > > > Right, I think there's still a great deal of value in having a simple > > recommendation for new users. > > Absolutely! The recurring problem with decisions like the one about the > recommended installers on the Haskell front page is that they are made by > power users who simply lack the perspective to understand the requirements > of new users. > > A minimal installer followed by half an hour of cabal install is an > extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, > but flexible is *bad* for newcomers. > > We are using Haskell in a few courses here at UNSW. We always recommend > students to use the Haskell Platform when they want to install Haskell on > their own machines. It?s one download and gives them the same packages on > all platforms. Anything else just leads to lots of support questions of > students trying to get their installations working to do their assignments. > > Manuel > > > One of the points of argument was that some people were arguing that the > > minimal installers are better for new users. I disagree, but certainly > > there is one issue that could be fixed that'd go a long way to resolving > > the particular use case with new users that was raised. > > > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the > landscape > >> for use to reconsider what to do. > > > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > > > > Well, the people who like it don't really complain. But yes, things need > > improving. > > > >> *1) Abandon the Platform.* GHC is release in source and binary form. > Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and > installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core > idea > >> around my "GPS Haskell" thoughts from last September - but there would > be > >> much to work out in this direction. > > > > I'm not sure that slimming is really needed. But I agree with the GPS > > approach. The current set is too small in the sense that it doesn't > > cover lots of things people need, and the GPS approach should solve > > that. We don't need to promise such high QA for the extended set, we > > just need to make sure they build together. > > > > We need to remember that one of the purposes of the platform as > > originally conceived is to get people to sync on the versions of their > > deps that they're using at the moment. This is where the GPS approach > > shines, but it still makes sense to have some core set at the middle of > > that. It's true that advanced users don't need lots of things > > pre-installed, but they sill benefit from other developers synchronising > > on versions of deps, so that they can have more things work together > > more often. > > > > On the argument that the platform is too big, the primary issue there is > > that people want to make new sandboxes that are more minimal, and with > > cabal's current behaviour of basing all sandboxes off of the global > > package db, and the platform installing lots of packages globally then > > we get a conflict. > > > > But the solution is simple: make cabal sandboxes not be based off of > > everything that is globally installed, make new sandboxes be really > > minimal (though the ghc/platform installers could help with identifying > > what is the minimal subset). > > > > Duncan > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > 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 gershomb at gmail.com Wed Mar 25 03:20:32 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 24 Mar 2015 23:20:32 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > > Right, I think there's still a great deal of value in having a simple > > recommendation for new users. > > Absolutely! The recurring problem with decisions like the one about the recommended > installers on the Haskell front page is that they are made by power users who simply lack > the perspective to understand the requirements of new users. To be clear, the current recommendations that highlight minimal installers were not made on behalf of ?power users.? In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries. The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: ?cabal? ?install? and ?ghci?. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context ? wipe the package environment and start again. The most important message for these new users is ?always use a sandbox?, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good. > A minimal installer followed by half an hour of cabal install is an extremely bad way to? > sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers.? I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn?t particularly inviting. Again, I very much _want_ to be able to recommend the platform unilaterally as the ?best choice nearly always?. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don?t understand why experienced users don?t always go with the platform (except, I suppose, if they are so accustomed to ?sandbox everything? that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still). I think Duncan?s proposals are very good. That is to say first, change the ?new sandbox behavior? issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope. In the interim, I did point out an outstanding ticket [2] on the homepage to further improve and balance the current layout and wording ? pull requests are always welcome!? Cheers, Gershom [1] a) Most recently, related to this discussion and linked by acowley: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/ b) Occasioned by the launch of the new homepage: http://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform_necessity_or_product/ [2] https://github.com/haskell-infra/hl/issues/55 > A minimal installer followed by half an hour of cabal install is an extremely bad way to > sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. > > We are using Haskell in a few courses here at UNSW. We always recommend students to use > the Haskell Platform when they want to install Haskell on their own machines. It?s one > download and gives them the same packages on all platforms. Anything else just leads > to lots of support questions of students trying to get their installations working to > do their assignments. > > Manuel > > > One of the points of argument was that some people were arguing that the > > minimal installers are better for new users. I disagree, but certainly > > there is one issue that could be fixed that'd go a long way to resolving > > the particular use case with new users that was raised. > > > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the landscape > >> for use to reconsider what to do. > > > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > > > > Well, the people who like it don't really complain. But yes, things need > > improving. > > > >> *1) Abandon the Platform.* GHC is release in source and binary form. Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core idea > >> around my "GPS Haskell" thoughts from last September - but there would be > >> much to work out in this direction. > > > > I'm not sure that slimming is really needed. But I agree with the GPS > > approach. The current set is too small in the sense that it doesn't > > cover lots of things people need, and the GPS approach should solve > > that. We don't need to promise such high QA for the extended set, we > > just need to make sure they build together. > > > > We need to remember that one of the purposes of the platform as > > originally conceived is to get people to sync on the versions of their > > deps that they're using at the moment. This is where the GPS approach > > shines, but it still makes sense to have some core set at the middle of > > that. It's true that advanced users don't need lots of things > > pre-installed, but they sill benefit from other developers synchronising > > on versions of deps, so that they can have more things work together > > more often. > > > > On the argument that the platform is too big, the primary issue there is > > that people want to make new sandboxes that are more minimal, and with > > cabal's current behaviour of basing all sandboxes off of the global > > package db, and the platform installing lots of packages globally then > > we get a conflict. > > > > But the solution is simple: make cabal sandboxes not be based off of > > everything that is globally installed, make new sandboxes be really > > minimal (though the ghc/platform installers could help with identifying > > what is the minimal subset). > > > > Duncan > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From chak at cse.unsw.edu.au Wed Mar 25 04:43:13 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 15:43:13 +1100 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: > Gershom B : > On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > >>> Right, I think there's still a great deal of value in having a simple >>> recommendation for new users. >> >> Absolutely! The recurring problem with decisions like the one about the recommended >> installers on the Haskell front page is that they are made by power users who simply lack >> the perspective to understand the requirements of new users. > > To be clear, the current recommendations that highlight minimal installers were not made on behalf of ?power users.? In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries. > > The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: ?cabal? ?install? and ?ghci?. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context ? wipe the package environment and start again. > > The most important message for these new users is ?always use a sandbox?, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good. You are talking about a specific kind of new users. These new users want to install a web stack or similar ? i.e., they need tons of packages. These people may be new to Haskell, but I reckon they are otherwise power users. I?m talking about somebody picking up Learn you a Haskell and wanting to write Hello World. Why should they care about sandboxes? Who cares if they mess up their installation by installing the wrong package. They can always nuke it and install it again. That?s a much simpler story. Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn?t use sandboxes either.) >> A minimal installer followed by half an hour of cabal install is an extremely bad way to >> sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. > > I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn?t particularly inviting. > > Again, I very much _want_ to be able to recommend the platform unilaterally as the ?best choice nearly always?. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don?t understand why experienced users don?t always go with the platform (except, I suppose, if they are so accustomed to ?sandbox everything? that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still). The mistake here is to try to make this a one-size-fits all. I honestly don?t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. If somebody gets sufficiently hooked on Haskell to want to start a bigger project, then they will have the patience for a more elaborate story (and wait for cabal install for a few hours to do its job). The point is that one-size-fits-all is inherently unfriendly to novices. A novice needs something simple with as few options as possible, whereas a power user wants flexibility and customisability. A minimal installer with sandboxes gives you the latter, but it comes at the expense of simplicity, which makes is unfriendly to novices. > I think Duncan?s proposals are very good. That is to say first, change the ?new sandbox behavior? issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope. Well, we have got people who want to learn Haskell now and who use Haskell as part of their coursework now. Why make them wait for future work which will probably take longer than planned, needs to be rolled out, etc? I?m sorry if I?m sounding negative here. I appreciate all these efforts. However, I am quite frustrated by the recurrent argument that flexibility implies simplicity. That is true for the expert, but flexibility is a curse to the beginner. Manuel From gershomb at gmail.com Wed Mar 25 05:09:02 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 25 Mar 2015 01:09:02 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > > Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular > type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon > he doesn?t use sandboxes either.) Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even ?stronger? sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir! > The mistake here is to try to make this a one-size-fits all. I honestly don?t care about > a platform that is ideal for everybody. I want something that I can point newbies at that > makes them happy quickly. That needs to be one download with all the packages that you > need to get going included. .. > Well, we have got people who want to learn Haskell now and who use Haskell as part of their? > coursework now. Why make them wait for future work which will probably take longer than? > planned, needs to be rolled out, etc? I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at?https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them ?the downloads page gives you options, pick the platform option.? Nobody who wants to use the platform must wait for anything. Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. We just want to recognize that this other set of users ? those coming from other languages, and wanting to ?from the gate? install large sets of dependencies ? this set of users has grown and is growing and if we don?t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a ?power user? and manage lots of dependencies with abandon you may want the minimal installers, and if you want ?a good, wide-ranging set of defaults to experiment and learn with? then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don?t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! Beyond that I don?t feel we?re discussing anything as metaphysical as flexibility or simplicity. And I don?t feel my own preferences are necessarily better or worse than others ? I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_.? As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. Best, Gershom From mark.lentczner at gmail.com Wed Mar 25 05:52:22 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 22:52:22 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote: > install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package > with an API binding for some webservice which has not been updated in two > years and requires an old version of time, and then maybe a GUI toolkit and > of course lens. That sounds like a recipe for Cabal Hell, Platform or not! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Mar 25 06:21:48 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 23:21:48 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Tue, Mar 24, 2015 at 10:09 PM, Gershom B wrote: > There are different types of beginners, and meeting all their needs (as > well as the needs of long-timers of various stripes, etc) all at once is a > tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet *all* users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: *The problem is how GHC is released:* It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. *This is an insufficient set of things for most users.* At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Mar 25 06:31:58 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 23:31:58 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: *Hey you....* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day? I know, I know, our process is long and full of discussion, and hard, and slow.... let's smash that, eh? How'z'bout it? OKAY? Good! Your task is: - look over the the source file at GitHub that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (copied below) - weigh in - short and sweet - if you have an opinion - if you have a spare Mac - download it and try it! Crazy, right? I know... but, can we do this? ? Mark On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 > using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the > Platform libs to the latest versions I could find on Hackage. There were a > few issues: > > - *old-locale and old-time* - no longer part of GHC, but > cabal-install, cgi & HTTP need them - and they are part of the platform - > so included now as added packages. Not sure this is a great idea, since > they are now very deprecated... but until cabal-install, cgi, & HTTP > update, not sure what else to do. > - *tf-random* - is now required by alex and QuickCheck - seems a shame > to add this, as now we're going to have two random packages > - *network-uri *- was split out of network, and needed by > cabal-install, cgi, & HTTP. I suppose we should include it, as it was > functionality and API that was part of the platform > - *exceptions* & *multipart* - needed by cgi - is exceptions now > subsumed by something in transformers? and... multipart? maybe time to drop > cgi? We didn't have it last time anyway as it wouldn't compile! > - *scientific* - needed by attoparsec - debated in detail last time > ... and we're still here! > > The Platform is significantly larger now: On OS X it has gone from 316M to > 499M! Most of this is due to new OpenGL libs which are now huge (went from > 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole > installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at > GitHub , > and the OS X builds are at my usual platform staging area: > > Index of /mark/platform > > > Remember, it already includes GHC, so no need to download the GHC binary > for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Wed Mar 25 06:33:40 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 17:33:40 +1100 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <5B7964AF-8532-457E-A24B-5C05AFA5A362@cse.unsw.edu.au> > Gershom B : > > On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: >> >> Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular >> type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon >> he doesn?t use sandboxes either.) > > Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even ?stronger? sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir! Then, I don?t understand why the Platform isn?t the recommended on the homepage. >> The mistake here is to try to make this a one-size-fits all. I honestly don?t care about >> a platform that is ideal for everybody. I want something that I can point newbies at that >> makes them happy quickly. That needs to be one download with all the packages that you >> need to get going included. > .. >> Well, we have got people who want to learn Haskell now and who use Haskell as part of their >> coursework now. Why make them wait for future work which will probably take longer than >> planned, needs to be rolled out, etc? > > I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them ?the downloads page gives you options, pick the platform option.? Nobody who wants to use the platform must wait for anything. > > Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. I know, but look at the subject of this message (and the original post in this thread). Mark?s questions was ?as I read it? do we still need the platform. Then, lots of power users jumped up and down criticising the flaws in the platform and why other approaches are better. To which I say, other approaches are better for you (plural)[1], but not to a large class of novices. That is all. Also, to reiterate, I?m arguing with you because you replied to my message. I definitely do appreciate all the effort you (and others) are putting into the homepage and infrastructure. Manuel [1] English is such an awkward language :P > We just want to recognize that this other set of users ? those coming from other languages, and wanting to ?from the gate? install large sets of dependencies ? this set of users has grown and is growing and if we don?t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. > > If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a ?power user? and manage lots of dependencies with abandon you may want the minimal installers, and if you want ?a good, wide-ranging set of defaults to experiment and learn with? then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don?t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! > > There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! > > Beyond that I don?t feel we?re discussing anything as metaphysical as flexibility or simplicity. And I don?t feel my own preferences are necessarily better or worse than others ? I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_. > > As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. > > Best, > Gershom > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From michael at snoyman.com Wed Mar 25 07:17:15 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 25 Mar 2015 07:17:15 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: Message-ID: I replied on the GSoC proposal itself, but since it was cross-posted to the mailing list, I'll include my comments here too: I've reviewed this proposal, and I think it outlines a step in a good direction. As I've discussed with Duncan in the past, my biggest concern around a system like this is the complexity of the UI for a developer; having to juggle different environments just to get basic work done could be a significant hurdle. As long as attention is paid to ensuring no "UI regression" for simple cases, I think this is worth pursuing. On Tue, Mar 24, 2015 at 7:17 PM Vishal Agrawal 1 wrote: > I am already planning to do a GSoC project based on it with a slightly > larger aim. You can find my work in progress proposal at > https://gist.github.com/fugyk/37510958b52589737274. Also I have written a > patch to make cabal non-destructive at > https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732e6a. > Can you review the proposal and give me suggestions. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Mar 25 07:22:49 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 25 Mar 2015 02:22:49 -0500 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Wed, Mar 25, 2015 at 1:21 AM, Mark Lentczner wrote: > On Tue, Mar 24, 2015 at 10:09 PM, Gershom B wrote: > > There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. > Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. My first reaction was "no, that's not right". Then I realized that it is - but only if the "common tool set" includes some kind of package search and installation tool. Which leads directly to: > At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. You have just defined the minimum platform. ghc, cabal-install, and the things needed for those. I think we also need better documentation than the current platform has. Go back to the case of moving beyond textbook exercises, which can tell you what packages to use, to trying to solve your own problems, no matter what they are. You will eventually wind up asking "What's the function/library/package to do X?". The documentation should guide users to the packages in the install, whether it's called "the Haskell Platform" or "ghc". I'm not qualified to pick the libraries. I'm not sure any one person is, or can be. But I can certainly help write documentation or tutorials for using them once they've been picked, and would be more than happy to do that. From hvr at gnu.org Wed Mar 25 07:55:11 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 08:55:11 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Tue, 24 Mar 2015 23:21:48 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <87egodtstc.fsf@gmail.com> On 2015-03-25 at 07:21:48 +0100, Mark Lentczner wrote: [...] > *The problem is how GHC is released:* It is released as a compiler, and > minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no > other tools, and no installer. *This is an insufficient set of things for > most users.* > > At minimum it should also have cabal-install, and the libs so many things > are built on: async, mtl, text, parsec, vector, etc..., and also common > tools (like happy, alex, and hscolour). You can argue plus or minus some of > these, the set could be bigger or smaller, ... basically, it should be the > Platform. > We should consider those additional libs as frozen, and tied to the GHC > release, as the base libs - because that will mean those will be the common > versions people will build and test against. And they will update as > frequently as GHC. (If they aren't as stable as all that, or aren't willing > to be part of that release cycle and constraint, then perhaps they > shouldn't be in that set!) > > Yes, I'm arguing that the GHC release and the Platform release should be > one and the same. The vast majority of the pain I think stems from the skew > between these two, and that GHC is not enough. You need something besides > the GHC release. If that something isn't standard, and/or it lags the GHC > release, then all the attendant problems creep in. [...] While I sympathise myself with bundling cabal-install with GHC bindists, as that's been (in my perception) the most requested feature from ghc-bindist users, GHC HQ is trying rather trying strip down the GHC distribution and dropping packages being installed by default whenever possible. E.g. with GHC 7.10.1 we dropped 4 packages (old-locale, old-time, haskell98, and haskell2010) as those don't need to be part of the (installed) GHC distribution. Some other packages (xhtml, haskeline, terminfo) that were recently exposed could be dropped again if we manage to workaround an unexpected DSO issue. We would even be in the position (since GHC 7.10) to drop the `Cabal` package from being installed (if it wasn't for the Cabal spec), as the `ghc` package severed its dependency on `Cabal` with this release.[1] Not tying packages to GHC releases gives more flexibility and less overhead, as we need to synchronise less with upstream maintainers, and more importantly updates to non-bundled packages can happen independently of GHC releases and more frequently. Also, it gives 3rd party packagers more degrees of freedom to select different cross-sections/subsets of Hackage to define as curated snapshot (i.e. LTS, Stackage, HP, Linux distributions, NixOS, ...). Cheers, hvr [1]: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/7571 From svenpanne at gmail.com Wed Mar 25 08:02:29 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 25 Mar 2015 09:02:29 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: 2015-03-25 7:31 GMT+01:00 Mark Lentczner : > [...] look over the the source file at GitHub that defines the release > see if the version of your stuff looks right The OpenGLRaw and GLUTRaw versions are OK, for OpenGL and GLUT we should use newer versions I just released (OpenGL-2.12.0.0 and GLUT-2.7.0.0). These contain much requested API additions/generalizations. Furthermore, due to other popular requests like generalizing things and making OpenAL stuff independent from OpenGL, I split off improved StateVar (thanks to Edward Kmett!) and ObjectName packages again, which are now additional dependencies. This move was made in spite of all those bikeshedding discussions around them, because several actual package users requested them. ("Listen to your customers!") I simply don't want to be held back by eternal theoretical discussions anymore, instead let's ship what people actually want. > [...] look near the end where there is a bunch of stuff I kinda just added to get > it all to compile [...] As mentioned above, we need StateVar-1.1.0.0 and ObjectName-1.1.0.0 now, too. A +1 for including exceptions, but why version 0.6.1, which is quite old? I would propose including the latest and greatest 0.8.0.2 version. Regarding the random packages: Shipping 2 packages for basically the same thing is silly IMHO and a bad sign for something which claims to be a coherent set of APIs. Either these packages should be merged or the dependencies adapted. Offering choice for the same task has no place in the platform IMHO, we should ship what is considered the best/most widely used for each area. For the more arcane needs, there's always Hackage... From hvr at gnu.org Wed Mar 25 08:12:07 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 09:12:07 +0100 Subject: wither the Platform In-Reply-To: (Manuel M. T. Chakravarty's message of "Wed, 25 Mar 2015 15:43:13 +1100") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <878uelts14.fsf@gnu.org> On 2015-03-25 at 05:43:13 +0100, Manuel M T Chakravarty wrote: [...] >> The most important message for these new users is ?always use a >> sandbox?, because that at least keeps them from destroying the full >> environment when they allow installations of packages that break >> other packages, etc. And the platform, to the extent that it changes >> and complicates build plans, does these users no good. > > You are talking about a specific kind of new users. These new users > want to install a web stack or similar ? i.e., they need tons of > packages. These people may be new to Haskell, but I reckon they are > otherwise power users. > > I?m talking about somebody picking up Learn you a Haskell and wanting > to write Hello World. IMO, that class of users don't need anything beyond the packages bundled with GHC anyway... However, LYAH already directs such users to the platform as it states in its introduction: | What you need to dive in | | A text editor and a Haskell compiler. You probably already have your | favorite text editor installed so we won't waste time on that. For the | purposes of this tutorial we'll be using GHC, the most widely used | Haskell compiler. | | *The best way to get started is to download the Haskell Platform,* | which is basically Haskell with batteries included.* | [...] And here's what Bird's "Thinking Functionally with Haskell" has to say about the HP: | 1.5 The Haskell Platform | | If you visit the site www.haskell.org, you will see how to download | The Haskell Platform. This is a large collection of tools and packages | that can be used to run Haskell scripts. The platform comes in three | versions, one for each of Windows, Mac and Linux. We deal only with | the Windows version, the others being similar. So I'm not too worried that newcomers following a guided course/tutorial (such as LYAH or TFwH) won't be directed to the platform. Cheers, hvr From johan.tibell at gmail.com Wed Mar 25 08:33:05 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 25 Mar 2015 09:33:05 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, "Mark Lentczner" wrote: > *Hey you....* yes you... Platform committee member, or Platform library > maintainer, Platform packager... that's right, you: > > GHC 7.10 is about to be released. Wouldn't it rock if we came out with a > Platform within days? Or on the same day? > > I know, I know, our process is long and full of discussion, and hard, and > slow.... let's smash that, eh? How'z'bout it? > > OKAY? Good! Your task is: > > - look over the the source file at GitHub > that > defines the release > - see if the version of your stuff looks right > - yeah, I bumped it all to latest, major or minor version change - so > APIs probably broke from last HP > - look near the end where there is a bunch of stuff I kinda just added > to get it all to compile > - read the notes about those things in the first message of this > thread (copied below) > - weigh in - short and sweet - if you have an opinion > - if you have a spare Mac - download it and try it! > > > Crazy, right? I know... but, can we do this? > > ? Mark > > On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner > wrote: > >> I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 >> using GHC 7.10 RC3. >> >> I bumped all the GHC libs to the versions in 7.10, and bumped all the >> Platform libs to the latest versions I could find on Hackage. There were a >> few issues: >> >> - *old-locale and old-time* - no longer part of GHC, but >> cabal-install, cgi & HTTP need them - and they are part of the platform - >> so included now as added packages. Not sure this is a great idea, since >> they are now very deprecated... but until cabal-install, cgi, & HTTP >> update, not sure what else to do. >> - *tf-random* - is now required by alex and QuickCheck - seems a >> shame to add this, as now we're going to have two random packages >> - *network-uri *- was split out of network, and needed by >> cabal-install, cgi, & HTTP. I suppose we should include it, as it was >> functionality and API that was part of the platform >> - *exceptions* & *multipart* - needed by cgi - is exceptions now >> subsumed by something in transformers? and... multipart? maybe time to drop >> cgi? We didn't have it last time anyway as it wouldn't compile! >> - *scientific* - needed by attoparsec - debated in detail last time >> ... and we're still here! >> >> The Platform is significantly larger now: On OS X it has gone from 316M >> to 499M! Most of this is due to new OpenGL libs which are now huge (went >> from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the >> whole installed magilla is 1.5G! Even the compressed installer is now 250M! >> >> If you want to poke at it, the source is in the pre-release branch at >> GitHub , >> and the OS X builds are at my usual platform staging area: >> >> Index of /mark/platform >> >> >> Remember, it already includes GHC, so no need to download the GHC binary >> for OS X that is there, too. >> >> I'll try to get a generic linux build up soonish... but my VM now runs >> out of memory trying to build OpenGL - and adding more only makes my >> machine thrash to death! >> >> - Mark >> >> > > _______________________________________________ > 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 hvr at gnu.org Wed Mar 25 08:33:41 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 09:33:41 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Tue, 24 Mar 2015 22:52:22 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <874mp9tr16.fsf@gnu.org> On 2015-03-25 at 06:52:22 +0100, Mark Lentczner wrote: > On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote: > >> install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package >> with an API binding for some webservice which has not been updated in two >> years and requires an old version of time, and then maybe a GUI toolkit and >> of course lens. > > That sounds like a recipe for Cabal Hell, Platform or not! Regardless of the hellish issue, Gershom's comment indirectly highlights of one thing where I'm wondering if the HP's growth isn't bounded by diversity: There are some areas which I'd expected to some degree in a batteries-included platform, where the Haskell ecosystem has diverged into popular but distinct package-sub-ecosystems (which all have their respective communities/followers), such as HTTP-serving (Yesod/Snap/Happstack/...), or which lens-abstraction to use, or at the more fundamental level, even the streaming abstraction (pipes/conduit/io-streams/machines/...) doesn't seem to have a clearly recommended and agreed upon representative. Also, to this day we don't have any TLS library support in the platform, which also is subject to debate of which crypto-library to use (and there's also the question whether to use OpenSSL via FFI or a native TLS reimpl). So the platform-included `HTTP` package is not even able to access `https://` URLs which is quite sad, as this also holds back `cabal-install`'s ability to access `https://`-only repositories. So, where do you see the platform's growth for those packages/areas where you'll probably not get a reasonable majority consensus for picking a specific package? Cheers, hvr From simonpj at microsoft.com Wed Mar 25 09:09:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Mar 2015 09:09:10 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ? There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. ? But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. ? The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That?s why GHC?s download page explicitly says ?Stop! Shouldn?t you be installing the Haskell Platform instead??. ? HP releases should therefore, in contrast to GHC releases, be widely publicised. ? Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a na?ve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that ?the GHC and the Platform release are one and the same?. I think of the HP release as the ?real GHC release?. It?s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: ? Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn?t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. ? Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: ? Is the original plan still good? ? Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it?s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B > wrote: There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. This is an insufficient set of things for most users. At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Mar 25 09:30:29 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 25 Mar 2015 04:30:29 -0500 Subject: wither the Platform In-Reply-To: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones wrote: > So that was the plan. I still think it?s a good plan. But it clearly > is not working well, and I?m hazy about why. Possible reasons: > Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform: ? On Windows, it does not provide a complete environment (missing MSYS). ? By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. ? The choice of package versions conflicts with the needs of many commonly used packages. ? Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Wed Mar 25 09:39:41 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Wed, 25 Mar 2015 09:39:41 +0000 Subject: TLS Support In-Reply-To: References: Message-ID: I don?t often venture an opinion here but I would be very much *against* using OpenSSL given the number of vulnerabilities it continues to experience. There?s http://www.mitls.org/wsgi/home which has been formally verified and our own https://hackage.haskell.org/package/tls. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com On 25 Mar 2015, at 09:08, libraries-request at haskell.org wrote: > Also, to this day we don't have any TLS library support in the platform, > which also is subject to debate of which crypto-library to use (and > there's also the question whether to use OpenSSL via FFI or a native TLS > reimpl). So the platform-included `HTTP` package is not even able to > access `https://` URLs which is quite sad, as this also holds back > `cabal-install`'s ability to access `https://`-only repositories. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Mar 25 09:49:10 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 25 Mar 2015 09:49:10 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Thanks for linking to that Mike, I'd actually forgotten that I'd written that :). Those are all very concrete issues people run into with the platform regularly, but I'd like to point out a meta issue: the platform tries to do too much, and in a non-composable manner. As I pointed out previously, it's providing a tools installer, choosing blessed libraries, pegging certain library versions, and selecting a distribution manner for those libraries. Even if the other issues were all addressed, I still believe the current trajectory of the platform is problematic, because it is necessarily removing choice. When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in my mind at least) was to allow individual tools to target individual goals. I don't expect every use case to be served by a curated package set (like LTS), so making that an optional feature of tooling makes sense. Similarly, almost all users (excepting some people playing with bleeding-edge GHC) will benefit from having an easy-to-use GHC+cabal-install installation, but a large set of users (specifically Hackage package authors) need a way to compile against different versions than the HP-blessed ones for testing purposes. And now a completely separate point: the current functioning of the HP process seems very much at odds with the way people actually write and release packages. Some examples: * Having to go through an extra step of requesting that a package version is bumped is tedious, and resulted in a buggy attoparsec being released in HP * Requiring package authors to endure long debate periods before the package is accepted scares people off from wanting to participate * A number of months back, the HP was used as a vehicle to push the PVP agenda as well, which completely alienated some people from wanting to participate (ironically, the package being pushed instead was not PVP compliant either, go figure). The practical result to that is we currently have no plans at all for getting TLS/HTTPS support into the platform, and everyone's tooling (cabal-install) is far less secure than it should be. * Authors want the freedom to quickly release new versions to their users, especially for bug fixes. While in theory the HP is set up to do bugfix releases, in practice this has never happened. In that sense, it is often preferable from the eyes of a package author *not* to have his/her package in the HP, as then users are better served As long as I'm writing a long email, I want to point out one other thing. A lot of the points being raised in this thread are discussing an idealized view of what the HP could become. I'm fully in favor of improving it (like I said, that's why I tried working with Mark on GPS Haskell and integrating with Stackage). However, we need to accept the reality of the situation today. Could the windows HP installer be improved like MinGHC to include MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work around the global package database issues we've been mentioning? Yes, and I support such moves. But we need to acknowledge current deficiencies, and plot out a course of action to solve them. And given that this thread started by lamenting how much effort the platform currently takes to maintain, I'm concerned about those improvements actually occurring. On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer wrote: > On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones > wrote: > >> So that was the plan. I still think it?s a good plan. But it clearly >> is not working well, and I?m hazy about why. Possible reasons: >> > > Possibly relevant is the stackage commentary on HP at > http://www.stackage.org/install#why-not-haskell-platform: > > ? On Windows, it does not provide a complete environment (missing MSYS). > ? By placing a large number of packages in the global package database, > Haskell Platform installations are more easily corrupted. > ? The choice of package versions conflicts with the needs of many commonly > used packages. > ? Some of the package versions included with the platform have known and > severe bugs, and cannot be reliably upgraded. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Mar 25 09:52:20 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Mar 2015 09:52:20 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Very good! This one is perhaps a missing piece, if you are saying that a Windows user cannot use GHC without MSYS: ? On Windows, it does not provide a complete environment (missing MSYS). On the other hand these three are examples of HP getting in the way: ? By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. ? The choice of package versions conflicts with the needs of many commonly used packages. ? Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. My question was: can they be fixed so that HP does not get in the way? E.g. if we solve the multiple-versions-of-packages problem with Cabal (which Duncan in a separate thread says we can), then that would solve the first two; and for the third, I guess the solution is to release a new version of HP. Simon From: Mike Meyer [mailto:mwm at mired.org] Sent: 25 March 2015 09:30 To: Simon Peyton Jones Cc: Mark Lentczner; Gershom B; Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones > wrote: So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform: ? On Windows, it does not provide a complete environment (missing MSYS). ? By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. ? The choice of package versions conflicts with the needs of many commonly used packages. ? Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Mar 25 10:10:37 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 11:10:37 +0100 Subject: wither the Platform In-Reply-To: (Simon Peyton Jones's message of "Wed, 25 Mar 2015 09:52:20 +0000") References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87zj71s7z6.fsf@gmail.com> On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote: [...] >> ? Some of the package versions included with the platform have known >> and severe bugs, and cannot be reliably upgraded. [...] > I guess the solution is to release a new version of HP. IMHO, if HP releases are to happen more frequently, a simple way to upgrade would be desirable rather than having to download a new multi-MiB full installer image each time only because a single package was updated (and the ability to have access to multiple HP releases side-by-side -- in case that isn't supported already) Or put differently, how shall HP users be informed they're not running the latest HP version with all known critical bugs fixed? Cheers, hvr From chak at cse.unsw.edu.au Wed Mar 25 10:14:46 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 21:14:46 +1100 Subject: wither the Platform In-Reply-To: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <9C597846-0885-45AD-B72E-6BDA54BA0070@cse.unsw.edu.au> Simon Peyton Jones : > So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: > > ? Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn?t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. > > ? Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. > I?d say, both. Re 1, a big part of the problem is the whole cabal, package dependency and versioning morass. Re 2, I think, there are multiple factors. The delays in putting out the HP (as previously mentioned). Power users reading GHC Status reports and wanting to get the goodies as quickly as possible. The HP just being quite a bit of hard work people like to avoid. Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Mar 25 10:15:37 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 25 Mar 2015 11:15:37 +0100 Subject: wither the Platform In-Reply-To: <87zj71s7z6.fsf@gmail.com> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87zj71s7z6.fsf@gmail.com> Message-ID: On Wed, Mar 25, 2015 at 11:10 AM, Herbert Valerio Riedel wrote: > Or put differently, how shall HP users be informed they're not running > the latest HP version with all known critical bugs fixed? While I can see most of the problems people claim the platform has, this particular one is shared by manual installs of packages. Cabal prefers installed version, so a package with a bug will not automatically be upgraded, and there is no warning informing users either. Erik From voldermort at hotmail.com Wed Mar 25 10:23:56 2015 From: voldermort at hotmail.com (Jeremy) Date: Wed, 25 Mar 2015 03:23:56 -0700 (MST) Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1427279036539-5767634.post@n5.nabble.com> Simon Peyton Jones wrote > My question was: can they be fixed so that HP does not get in the way? > E.g. if we solve the multiple-versions-of-packages problem with Cabal > (which Duncan in a separate thread says we can), then that would solve the > first two; and for the third, I guess the solution is to release a new > version of HP. Or we could follow what Microsoft have done to solve this problem with .NET, and move non-GHC packages out of the platform into a separate delivery vehicle - which could be bundled with the platform if desired. As it stands, the platform cannot simply update packages without a full install. This is the essence of our problem - update the platform libraries independently of a GHC/platform release. (In the same way that you can upgrade the packages which were installed with a specific version of a Linux distro, or use NuGet to upgrade packages that were released with a .NET platform.) -- View this message in context: http://haskell.1045720.n5.nabble.com/wither-the-Platform-tp5767291p5767634.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From mark.lentczner at gmail.com Wed Mar 25 14:24:30 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 25 Mar 2015 07:24:30 -0700 Subject: wither the Platform In-Reply-To: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: > Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, > was this: ... > I still like that plan! Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!* *Pare the Platform Back:* Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. *And, make that stuff be the latest it can be at each release. *The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. *Make sure the Platform Installers are Complete:* I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. *Make Updating the Packages in Cabal 'work':* I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. *One Web Site:* Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Mar 25 14:34:20 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 25 Mar 2015 10:34:20 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 10:24 AM, Mark Lentczner wrote: > The OpenGL stuff is a hard one, since it is large, but a very big painful > build if you need it. Perhaps we need server/non-server versions of the > platform - but only if we can get them out on the same day. OpenGL has always been an odd fit; it was included partly because of the size and complexity to build, but also because it was felt that batteries-included had to include *some* kind of graphics library. I'm inclined to think that it doesn't really belong in the core Platform, myself. -- 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 howard_b_golden at yahoo.com Wed Mar 25 17:34:08 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 25 Mar 2015 17:34:08 +0000 (UTC) Subject: wither the Platform In-Reply-To: References: Message-ID: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between "latest and greatest" and "batteries included." While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction. Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to "step up": The research community will need to accept a more structured deployment of their innovations. Howard ________________________________ From: Mark Lentczner Sent: Wednesday, March 25, 2015 7:24 AM Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! > > >Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. > > >Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. > > >Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. > > >One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. > > This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From strake888 at gmail.com Wed Mar 25 20:06:47 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Wed, 25 Mar 2015 15:06:47 -0500 Subject: Generalize filterM to Applicative In-Reply-To: <54AAC177.8070600@stilo.com> References: <54A19DFC.7000909@ifi.lmu.de> <54AAC177.8070600@stilo.com> Message-ID: <20150325200647.GA7241@mintha> On 05/01/2015 at 11:53:11 -0500, Mario Bla?evi? wrote: > On 14-12-30 12:34 PM, David Feuer wrote: > >I realized just now that we can actually make the type a little bit > >more general still, interpreting `filterM` for lists as being an > >applicative filter *producing* lists: > > > >filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a] > > I'm +1 on the more limited generalization proposal, but not on this one. > I've been feeling for a while that we need a subclass of Traversable to > generalize functions like filter, mapMaybe, and partition (potentially span, > splitAt and others as well). If you call this missing class Filterable, the > properly-generalized signature would be > > > filterM :: (Applicative f, Filterable t) => > > (a -> f Bool) -> t a -> f (t a) https://hackage.haskell.org/package/witherable Interesting name choice... From strake888 at gmail.com Wed Mar 25 20:20:52 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Wed, 25 Mar 2015 15:20:52 -0500 Subject: Generalize filterM to Applicative In-Reply-To: <20150325200647.GA7241@mintha> References: <54A19DFC.7000909@ifi.lmu.de> <54AAC177.8070600@stilo.com> <20150325200647.GA7241@mintha> Message-ID: <20150325202052.GA7476@mintha> On 25/03/2015 at 15:06:47 -0500, M Farkas-Dyck wrote: > https://hackage.haskell.org/package/witherable > > Interesting name choice... This has superclass Traversable tho, which is not needed as wither f xs = catMaybes <$> traverse f xs filterA f = mapMaybeA (\ x -> (x <$) . guard <$> f x) From cheecheeo at gmail.com Wed Mar 25 21:01:58 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Wed, 25 Mar 2015 14:01:58 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Tue, Mar 24, 2015 at 11:31 PM, Mark Lentczner wrote: > *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi > & HTTP need them - and they are part of the platform - so included now as > added packages. Not sure this is a great idea, since they are now very > deprecated... but until cabal-install, cgi, & HTTP update, not sure what > else to do.... *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by > something in transformers? and... multipart? maybe time to drop cgi? We > didn't have it last time anyway as it wouldn't compile! Mark, Thanks for all your hard work on the platform. Haskell Platform compliance is not currently a goal of cgi and since it wasn't in the platform last round I'd say it should be treated as a package attempting to be accepted into the Haskell Platform. Are old-time and old-locale really deprecated? If so, can libraries at haskell.org use the nifty 'Deprecated in favor of ...' feature of hackage like MonadCatchIO-mtl [1] does? Regarding depedencies, since I've taken over maintenance of cgi the primary goal has been getting it able to compile with the latest GHC. Compiling with GHC 7.8 meant dropping MonadCatchIO-mtl and using exceptions. multipart is nearly a bit for bit copy of some internal cgi code, rather than duplicating the code, cgi added it as a dependency. [1] http://hackage.haskell.org/package/MonadCatchIO-mtl -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Mar 26 09:36:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Mar 2015 09:36:04 +0000 Subject: wither the Platform In-Reply-To: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> References: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5e71ff0c20374a578c6e3844577f3407@DB4PR30MB030.064d.mgd.msft.net> | 2. Less diversity in new GHC features: The GHC developers have generally | aimed new features at a future release, where the existence and stability | of new features has driven their incorporation. It was assumed that the | Platform would eventually catch up. If the GHC release and the | corresponding Platform release are simultaneous, then some GHC features | may need to be pushed out to the following release so there is time for | the Platform to be adapted. | 3. The GHC development process will need to become more phased: | Experimentation with new features will still be encouraged, but adoption | of the new features will need to be gated to correspond with what the | Platform can implement. (This is really another view of issue 2.) I'm not sure that's true. We try hard not to break backward compatibility with new features. So a new GHC/HP release might have new features in GHC that are simply un-exploited by the HP libraries. That's fine! By far the biggest backward-compat issues are related to changes in the libraries themselves, rather than new features. Simon From hesselink at gmail.com Thu Mar 26 09:39:48 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 26 Mar 2015 10:39:48 +0100 Subject: quick report using GHC 7.10 RC3 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner wrote: > 7. Cabal incompatible API change > In particular, the api that a custom Setup.hs uses. > Distribution.Simple.UserHooks changed the type of a hook. It should not, it > should have added another to do what it wanted. The poblem is you can't use > CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: > Your Setup.hs can't work in both 7.10 and 7.8! It can, but it's a bit tricky. When this happened before, people used a type class with two instances, where one of them filled in a default argument, IIRC. I can't find the exact code now, perhaps others remember this better. Erik From simonpj at microsoft.com Thu Mar 26 09:40:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Mar 2015 09:40:44 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <9500237d82fa4680828718f2b4cc462c@DB4PR30MB030.064d.mgd.msft.net> Good plan. You didn?t mention a key point: ? Make sure that installing the Platform doesn?t get in the way, if you subsequently want to upgrade libraries or whatever. I am un-clear about precisely what the problem(s) is/are here. I?m pretty sure they require infrastructure work (in Cabal) to achieve. Simon From: Mark Lentczner [mailto:mark.lentczner at gmail.com] Sent: 25 March 2015 14:25 To: Simon Peyton Jones Cc: Gershom B; Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones > wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Mar 26 09:54:59 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 26 Mar 2015 09:54:59 +0000 Subject: quick report using GHC 7.10 RC3 In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 11:40 AM Erik Hesselink wrote: > On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner > wrote: > > > 7. Cabal incompatible API change > > In particular, the api that a custom Setup.hs uses. > > Distribution.Simple.UserHooks changed the type of a hook. It should not, > it > > should have added another to do what it wanted. The poblem is you can't > use > > CPP in Setup.hs. And so now anyone using the testHook hook is in a > pickle: > > Your Setup.hs can't work in both 7.10 and 7.8! > > It can, but it's a bit tricky. When this happened before, people used > a type class with two instances, where one of them filled in a default > argument, IIRC. I can't find the exact code now, perhaps others > remember this better. > > > I wrote a blog post in June of last year[1] and was told that some of those tricks are used to Cabal files. I also don't have a link to a real example, but the blog post may help. Michael [1] http://www.yesodweb.com/blog/2014/06/evil-conditional-compile -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Mar 26 20:19:51 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 26 Mar 2015 16:19:51 -0400 Subject: ansi-wl-pprint Message-ID: ansi-wl-pprint sits underneath a large chunk of our infrastructure: test-framework, criterion, trifecta, etc. Transitively through those dependencies it affects a very large percentage of the Haskell packages we have today, because you can't build almost anybody's testing and benchmarking frameworks without it. We recently had to push out an non-maintainer update for GHC 7.10-rc3 compatibility, and due to NMU update guidelines meant we had to wait 2 weeks before we could do anything. This pretty much ensured that the entire 7.10-rc3 release cycle went by with very very few people able to run their test suites, and little testing was able to be performed in the allotted window. Fortunately, Neil managed to find a rather large regression on his own during this time: http://neilmitchell.blogspot.com/2015/03/finding-ghc-bug.html That said, given that we found issues with linear caused by the changes to Typeable, once we fixed the test suite, this gives me pause. I'm pretty sure nobody downstream of linear tried to run their test suites on rc3. I'd like to not find ourselves in that situation again. We have a policy of considering requests for maintainership transfer after ~6 months of inactivity. Max has been inactive for over a year. I'd like to invoke that today, and formally request to take over maintainership of ansi-wl-pprint. All of the visible activity on https://github.com/batterseapower in the last year or so is on java projects. We've already adopted test-framework. In the event Max returns to active status in the Haskell community, I'd happily relinquish control. Thank you for your consideration, -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Mar 26 20:29:07 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 26 Mar 2015 21:29:07 +0100 (CET) Subject: ansi-wl-pprint In-Reply-To: References: Message-ID: On Thu, 26 Mar 2015, Edward Kmett wrote: > We recently had to push out an non-maintainer update for GHC 7.10-rc3 > compatibility, and due to NMU update guidelines meant we had to wait 2 > weeks before we could do anything. This pretty much ensured that the > entire 7.10-rc3 release cycle went by with very very few people able to > run their test suites, and little testing was able to be performed in > the allotted window. Can't you test with a fixed but unreleased version of ansi-wl-pprint? From the.dead.shall.rise at gmail.com Thu Mar 26 20:42:05 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 26 Mar 2015 21:42:05 +0100 Subject: ansi-wl-pprint In-Reply-To: References: Message-ID: Hi, On 26 March 2015 at 21:29, Henning Thielemann wrote: > > [...] > Can't you test with a fixed but unreleased version of ansi-wl-pprint? In case your question is not rhetorical: yes, it's surely possible. We used this workaround to fix Cabal's build bot. From michael at snoyman.com Thu Mar 26 20:44:53 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 26 Mar 2015 20:44:53 +0000 Subject: ansi-wl-pprint In-Reply-To: References: Message-ID: I support this move. On Thu, Mar 26, 2015, 10:20 PM Edward Kmett wrote: > ansi-wl-pprint sits underneath a large chunk of our infrastructure: > test-framework, criterion, trifecta, etc. > > Transitively through those dependencies it affects a very large percentage > of the Haskell packages we have today, because you can't build almost > anybody's testing and benchmarking frameworks without it. > > We recently had to push out an non-maintainer update for GHC 7.10-rc3 > compatibility, and due to NMU update guidelines meant we had to wait 2 > weeks before we could do anything. This pretty much ensured that the entire > 7.10-rc3 release cycle went by with very very few people able to run their > test suites, and little testing was able to be performed in the allotted > window. > > Fortunately, Neil managed to find a rather large regression on his own > during this time: > http://neilmitchell.blogspot.com/2015/03/finding-ghc-bug.html > > That said, given that we found issues with linear caused by the changes to > Typeable, once we fixed the test suite, this gives me pause. I'm pretty > sure nobody downstream of linear tried to run their test suites on rc3. > > I'd like to not find ourselves in that situation again. > > We have a policy of considering requests for maintainership transfer after > ~6 months of inactivity. Max has been inactive for over a year. > > I'd like to invoke that today, and formally request to take over > maintainership of ansi-wl-pprint. > > All of the visible activity on https://github.com/batterseapower in the > last year or so is on java projects. > > We've already adopted test-framework. > > In the event Max returns to active status in the Haskell community, I'd > happily relinquish control. > > Thank you for your consideration, > > -Edward > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Mar 26 20:55:21 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 26 Mar 2015 16:55:21 -0400 Subject: ansi-wl-pprint In-Reply-To: References: Message-ID: I did so. I don't know that almost anybody else did. -Edward On Thu, Mar 26, 2015 at 4:29 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > > On Thu, 26 Mar 2015, Edward Kmett wrote: > > We recently had to push out an non-maintainer update for GHC 7.10-rc3 >> compatibility, and due to NMU update guidelines meant we had to wait 2 >> weeks before we could do anything. This pretty much ensured that the entire >> 7.10-rc3 release cycle went by with very very few people able to run their >> test suites, and little testing was able to be performed in the allotted >> window. >> > > Can't you test with a fixed but unreleased version of ansi-wl-pprint? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Fri Mar 27 05:36:35 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Fri, 27 Mar 2015 18:36:35 +1300 Subject: [Haskell-cafe] ListT considered harmful In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 5:07 PM, Michael Snoyman wrote: > I'm in favor of deprecation, but opposed to removing any time soon due to > backwards compatibility concerns. I agree. Given that we just deprecated ErrorT (which is both more popular, and does follow the monad laws) I think there is good reason to phase out transformers' ListT as well. I've attached a patch that adds the relevant pragma. I'm not familiar with darcs so excuse me if it's messed up :) libraries list and/or Ross Paterson, do you have anything to say about this issue? > On Fri, Mar 27, 2015 at 7:03 AM Fumiaki Kinoshita > wrote: >> >> It is well known that ListT m in transformers is not a monad unless the >> underlying monad is commutative. The fact that ListT is not a monad >> transformer is sufficient to remove it from the package, and several >> packages already defined their own ListT. >> >> Oughtn't we deprecate ListT or replace it by a correct one? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong https://lambda.xyz -------------- next part -------------- New patches: [Deprecate Control.Monad.Trans.List Chris Wong **20150327045544 Ignore-this: 803a54f83f75fb1282172857c0451223 The ListT in this module is not a monad in the general case, requiring a tricky invariant (commutativity in the base monad) to use properly. There are plenty of packages which provide a "ListT done right", and we should encourage new users to depend on those instead. ] hunk ./Control/Monad/Trans/List.hs 20 -- which must be commutative. ----------------------------------------------------------------------------- -module Control.Monad.Trans.List ( +module Control.Monad.Trans.List + {-# DEPRECATED "Use the 'list-t' or 'pipes' packages instead" #-} + ( -- * The ListT monad transformer ListT(..), mapListT, Context: [move eq1, etc out of the classes Ross Paterson **20150325235706 Ignore-this: 23902fc2118e73528ef7d9b33dcd2410 ] [fix warnings Ross Paterson **20150325235322 Ignore-this: 5228163ad420d6b7befab60e7d572714 ] [instances of Eq2, Ord2, Read2 and Show2 Ross Paterson **20150325214456 Ignore-this: 394da2a95af800f78a602423da316e3d ] [switch liftings of Prelude classes to use explicit dictionaries Ross Paterson **20150325192309 Ignore-this: 8678c8c82d9d9ca34004a022d1d90f78 ] [fix foldr1/foldl1 for Backwards (spotted by Ryan Scott) Ross Paterson **20150324144124 Ignore-this: ac68e0a000afa5e9e48c405c0303f889 ] [TAG 0.4.3.0 Ross Paterson **20150308183108 Ignore-this: 1dec0ecddd2fdbfed11232edc4dd362e ] Patch bundle hash: 9c2ea89fbf6f1638d63ea4df165f40359c7cb94b From hvr at gnu.org Fri Mar 27 12:24:37 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 27 Mar 2015 13:24:37 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Wed, 25 Mar 2015 07:24:30 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87r3saocfu.fsf@gnu.org> On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote: [...] > Concrete proposal based on that and the other fine input in the responses: > > *Simultaneous Release:* Since it is organizationally impractical to have > one release, let's have GHC and Platform release at the same moment. That > is, GHC HQ would keep a release in "RC" until HP was ready. By the same > token, HP team commits to tracking GHC from RC1, and aiming to hit ready > for release within a week of GHC being ready. Both go "release" in the same > announcement. *In fact, let's version HP with the same number as GHC!* [...] I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, while penalising those users that have no interest to use the HP anyway. Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) -- hvr From mark.lentczner at gmail.com Fri Mar 27 14:09:42 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:09:42 -0700 Subject: wither the Platform In-Reply-To: <87r3saocfu.fsf@gnu.org> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel wrote: > I'm a bit worried about the aspect of delaying the GHC release schedule > for the sole purpose to provide the HP with more visibility, That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion is to ensure that there is a consistent way for the community to "get Haskell" (as GHC itself is not enough for anyone - you need cabal at the least, and there are libraries that are common enough to be considered essential: text, vector, etc...). It is also to ensure there is a consistent reference point for package developers to test their packages against, for those packages that wish to support more than just the current GHC. Again, GHC releases themselves do not form a big enough reference point to ensure two packages that "support the last two release" are supporting the same thing. ... > Otoh, > there's usually enough time between the last RC and the actual final > release, which should give the HP at least one week of time anyway w/o > any active delay on GHC's end. > Well - if there is a week of commits to GHC, it should really do another RC before declaring it final. The difference between the last RC and the release should a single commit of no more than the version number change and the change log. Frankly, if we are all on board with this, then GHC could suffer a few day (week at most) delay between such an RC (as in "we're frozen, save for the version stamp"), and announcing "release". This would not only allow there to be a Platform on the same day - but also GHC bindists for other OSes on the same day. > Otoh, as soon as the new HP is released, it provides users with the > perception of a new stable HP release to jump on right-away. That, > however, may lead to a poor experience if the it's the first HP release > for a given major GHC version as Hackage usually hasn't fully caught up > by the time a GHC x.y.1 is unleashed. We need to have to maintainers of the packages in the HP on board with this and down with the "we're all going to gear up in the four weeks before a GHC version"... not "we'll gear up in the four weeks after". Frankly, for the kinds of packages that are in the platform (text, vector, unordered containers, etc...), having these packages lag GHC release so that they are broken on Hackage the day of GHC release is in nobody's interest: It gives a poor experience for ALL users of Haskell. So if we had co-released a HP > featuring GHC 7.10.1 today, there would still be enough Hackage packages > not yet compatible with GHC 7.10.1 to recommend users *not* to install > the release right-away. > But that is true of GHC as well. We need to stop having the attitude of "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible." Then our recommendations on to users on IRC are about which version is best for their needs, not "don't install platform, you won't be able to get lens to compile..." > So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP > would be in the HP's best interest in terms of providing a reliable and > complete development environment (which IMO requires access to Hackage, > even more so if the HP is to be reduced to contain less packages) > People who care about stability will go ahead and hang back to what they consider a stable reference for them. (Gosh, how many projects are still supporting Python 2.6?!). But it will only be a "stable reference" if people use it, and package maintainers support it. Today's mess of GHC releases, Platform releases, alternative installer releases, etc... leaves both users and package maintainers no way to create or find stability. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Mar 27 14:27:38 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Mar 2015 10:27:38 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner wrote: > But that is true of GHC as well. We need to stop having the attitude of > "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine > to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 > which is a complete installer for your OS with core and standard libraries, > and tools; or if you prefer you can get the minimal binary compiler build. > As always, not all packages on Hackage will be compatible." Then our > recommendations on to users on IRC are about which version is best for > their needs, not "don't install platform, you won't be able to get lens to > compile..." > The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 27 14:35:36 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:35:36 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett wrote: > The lens package (alongside every other package I maintain that is > incurred as a dependency of lens) has very > deliberately support all Haskell Platform releases for at least 3 current > major GHC releases, often at great expense to the API. > > No offense, but I don't think lens is the culprit here. > Excellent! None taken. I appologize for my poor choice of example. Several people have included lens in an example of "newcomers want to install x, y, and z - and it won't work with the platform." It is great that lens is not the problem - but it does underscore that the other packages haven't seen fit to match the same stability release points as lens - hence the unlikeliness of them working together except at HEAD. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 27 14:41:27 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:41:27 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do "with and without" releases. Votes? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Mar 27 15:28:45 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Mar 2015 11:28:45 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: I'm personally a rather vocal proponent of the new OpenGL API changes. I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together. The hand-wringing we've had over the splitting off of multipart from cgi and ObjectName or StateVar from OpenGL because designers of packages like sdl2 want to be able to support a common API without incurring a needless OpenGL dependency is largely indicative of why some folks get scared of their packages being included in the platform. And, e.g. aeson's scientific dependency is needed to ensure data going through the API doesn't lose precision, and due to stackage almost everyone has adapted to its presence for over a year. Removing it would do nobody any good. Let's bless it and move on. -Edward On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner wrote: > NO MOAR BIKESHEDS! > > I don't want to release in the platform an API that is out of date the day > we release it. So we either go with the new (and I'm trusting Sven to vouch > for 'it's the right API, we'll support this for the next year or so') - or > we drop OpenGL* from the platform release - or we do "with and without" > releases. > > Votes? > ? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Mar 27 18:50:53 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 27 Mar 2015 14:50:53 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. At the very least, we should try to get that new version of primitive ready for release and onto platform, since it immediately upgrades the power of any package that uses prim monad! On Mar 27, 2015 11:28 AM, "Edward Kmett" wrote: > I'm personally a rather vocal proponent of the new OpenGL API changes. > > I'd also in general favor a policy of greater trust when it comes to > library authors factoring out bits of their packages even once they become > part of the platform. We all want our code to work together. > > The hand-wringing we've had over the splitting off of multipart from cgi > and ObjectName or StateVar from OpenGL because designers of packages like > sdl2 want to be able to support a common API without incurring a needless > OpenGL dependency is largely indicative of why some folks get scared of > their packages being included in the platform. > > And, e.g. aeson's scientific dependency is needed to ensure data going > through the API doesn't lose precision, and due to stackage almost everyone > has adapted to its presence for over a year. Removing it would do nobody > any good. Let's bless it and move on. > > -Edward > > On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner > wrote: > >> NO MOAR BIKESHEDS! >> >> I don't want to release in the platform an API that is out of date the >> day we release it. So we either go with the new (and I'm trusting Sven to >> vouch for 'it's the right API, we'll support this for the next year or so') >> - or we drop OpenGL* from the platform release - or we do "with and >> without" releases. >> >> Votes? >> ? >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > 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 mark.lentczner at gmail.com Sat Mar 28 02:46:43 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 19:46:43 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Relatedly, theres a major version bump release of primitive that's due to > be cut soon, and in a month or two vector 0.11 will be ready for release > one way or another. > > Is "soon" measured in hours? If not - I suggest that it misses. I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those "it's almost there" packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Mar 28 02:58:55 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 27 Mar 2015 22:58:55 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > Is "soon" measured in hours? If not - I suggest that it misses. > > I'm pushing that we change how we do this Platform thing - and make it > stick, like glue, to the GHC release schedule. Sure, this time 'round we'll > be out of sync with those "it's almost there" packages... but next time > we'll know it's coming and hopefully, we'll have these panic attacks as GHC > is in beta not post-Release. +1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we?ll always be playing catch-up to ?one more thing.? -g From dan.doel at gmail.com Sat Mar 28 03:02:42 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 27 Mar 2015 23:02:42 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Soon is now. I just published primitive-0.6 and vector-0.10.12.3 that increments the version dependency for it. So they can go in if people want. -- Dan On Fri, Mar 27, 2015 at 10:46 PM, Mark Lentczner wrote: > > On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Relatedly, theres a major version bump release of primitive that's due to >> be cut soon, and in a month or two vector 0.11 will be ready for release >> one way or another. >> >> > Is "soon" measured in hours? If not - I suggest that it misses. > > I'm pushing that we change how we do this Platform thing - and make it > stick, like glue, to the GHC release schedule. Sure, this time 'round we'll > be out of sync with those "it's almost there" packages... but next time > we'll know it's coming and hopefully, we'll have these panic attacks as GHC > is in beta not post-Release. > > - Mark > > _______________________________________________ > 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 malcolm.wallace at me.com Sat Mar 28 11:59:42 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sat, 28 Mar 2015 11:59:42 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: <5DBD6BF3-0069-48C3-AEEA-018EE7C72085@me.com> With the advent of efficient build tools, would it be too outrageous to suggest we start to move to automated HP releases on an even faster (but rigid) schedule, e.g. weekly, or monthly? As new versions of libraries come out, they could be incorporated in the platform as soon as they are verified to build successfully with the other dependencies, and the next weekly/monthly bundle would have it. Then there would always be a "recent" Platform good enough for even the bleeding-edge types of users. It would eliminate the rush of "please can we hold off until foo is released in a few days time" requests, which has tended to cause schedule-drift in the past. Continuous integration FTW! Regards, Malcolm On 28 Mar 2015, at 02:58, Gershom B wrote: > On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: >> Is "soon" measured in hours? If not - I suggest that it misses. >> >> I'm pushing that we change how we do this Platform thing - and make it >> stick, like glue, to the GHC release schedule. Sure, this time 'round we'll >> be out of sync with those "it's almost there" packages... but next time >> we'll know it's coming and hopefully, we'll have these panic attacks as GHC >> is in beta not post-Release. > > +1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we?ll always be playing catch-up to ?one more thing.? > > -g > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From mark.lentczner at gmail.com Sat Mar 28 16:48:26 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 09:48:26 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne wrote: > A +1 for including exceptions, but why version 0.6.1, which is quite > old? I would propose including the latest and greatest 0.8.0.2 > version. > Ah - because gci 3001.2.2.0 has a bound on exceptions < 0.7. John Chee: I don't want to ship an old exceptions. Can update cgi or shall we keep cgi out this time 'round? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Sat Mar 28 17:11:51 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Sat, 28 Mar 2015 18:11:51 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Just needs a bumped upper bound it seems. On Sat, Mar 28, 2015 at 5:48 PM, Mark Lentczner wrote: > > On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne wrote: > >> A +1 for including exceptions, but why version 0.6.1, which is quite >> old? I would propose including the latest and greatest 0.8.0.2 >> version. >> > > Ah - because gci 3001.2.2.0 has a bound on exceptions < 0.7. > > John Chee: I don't want to ship an old exceptions. Can update cgi or shall > we keep cgi out this time 'round? > > - Mark > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheecheeo at gmail.com Sat Mar 28 17:28:44 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Sat, 28 Mar 2015 10:28:44 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Mark: I'm bumping the dependency on exceptions now. I'll post back before noon PDT if I get a release out. If the entire platform release is blocked on this though, go ahead without cgi. Adam: Thanks for the investigation. On Sat, Mar 28, 2015 at 10:11 AM, Adam Bergmark wrote: > Just needs a bumped upper bound it seems. > > On Sat, Mar 28, 2015 at 5:48 PM, Mark Lentczner > wrote: > >> >> On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne wrote: >> >>> A +1 for including exceptions, but why version 0.6.1, which is quite >>> old? I would propose including the latest and greatest 0.8.0.2 >>> version. >>> >> >> Ah - because gci 3001.2.2.0 has a bound on exceptions < 0.7. >> >> John Chee: I don't want to ship an old exceptions. Can update cgi or >> shall we keep cgi out this time 'round? >> >> - Mark >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 17:49:20 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 10:49:20 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee < cheecheeo at gmail.com> wrote: > Mark: I'm bumping the dependency on exceptions now. I'll post back before > noon PDT if I get a release out. > Rockin'! All: I appreciate the crazy weekend scramble! Alas, for me during the week I'm swamped with work (a good thing - it means my project there is going very well!) If this sync'ing with GHC releases path is well received, then next time we'll have a bit more (~1 month) runway! - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheecheeo at gmail.com Sat Mar 28 18:01:22 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Sat, 28 Mar 2015 11:01:22 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Mark, Release: http://hackage.haskell.org/package/cgi-3001.2.2.1 Platform pull request: https://github.com/haskell/haskell-platform/pull/169 On Sat, Mar 28, 2015 at 10:49 AM, Mark Lentczner wrote: > On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee < > cheecheeo at gmail.com> wrote: > >> Mark: I'm bumping the dependency on exceptions now. I'll post back before >> noon PDT if I get a release out. >> > > Rockin'! > > All: I appreciate the crazy weekend scramble! Alas, for me during the week > I'm swamped with work (a good thing - it means my project there is going > very well!) If this sync'ing with GHC releases path is well received, then > next time we'll have a bit more (~1 month) runway! > > - Mark > -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 22:23:02 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 15:23:02 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 Message-ID: I have built the 7.10.1 bindist for OS X. It is currently sitting on my server at: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 \O/ I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X . It is based on the above bindist. I should have an ubuntu version of the Platform built by tomorrow. \O/ - Mark *sha256 sums:* c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee ghc-7.10.1-x86_64-apple-darwin.tar.bz2 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 22:37:46 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 15:37:46 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Thanks, John! Alpha 2 is now out: - github commit - OS X Build: Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg Notable changes: - Based on GHC 7.10.1 release - updated attoparsec - updated cgi - brand spanking new major release of OpenGL & GLUT (and related packages) - brand new primitive - updated vector - modern exceptions - updated cabal-install - added ObjectName, StateVar, and transformers-compat, needed by the above Whew! I'll be building the ubuntu based generic build tonight (just got a brand new Intel NUC for this!) Keep the cards and letters coming! Test it out! Review the versions! *Look over the issues list on GitHub , and see if there is anything we need to fix before going final sometime in the next few days.* - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From alec at deviant-logic.net Sat Mar 28 22:42:54 2015 From: alec at deviant-logic.net (Alec) Date: Sat, 28 Mar 2015 22:42:54 +0000 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: Thanks Mark! But: % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 Also, `tar xjf` didn't like it very much. Did your upload get cut off? The tarball is only 77 Megs. -A On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner wrote: > I have built the 7.10.1 bindist for OS X. > It is currently sitting on my server at: > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > > \O/ > > I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X > . > It is based on the above bindist. > I should have an ubuntu version of the Platform built by tomorrow. > \O/ > > - Mark > > *sha256 sums:* > c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell > Platform 2015.2.0.0 alpha 2 64bit.pkg > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at redivi.com Sat Mar 28 23:03:18 2015 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 Mar 2015 16:03:18 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: I'm having the same issue with that build. On Sat, Mar 28, 2015 at 3:42 PM, Alec wrote: > Thanks Mark! But: > > % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65 > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > > Also, `tar xjf` didn't like it very much. Did your upload get cut off? > The tarball is only 77 Megs. > > -A > > On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner > wrote: > >> I have built the 7.10.1 bindist for OS X. >> It is currently sitting on my server at: >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> >> \O/ >> >> I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X >> . >> It is based on the above bindist. >> I should have an ubuntu version of the Platform built by tomorrow. >> \O/ >> >> - Mark >> >> *sha256 sums:* >> c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell >> Platform 2015.2.0.0 alpha 2 64bit.pkg >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Mar 28 23:29:21 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 28 Mar 2015 19:29:21 -0400 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: I'll kick off my own build for os x this evening. On Saturday, March 28, 2015, Bob Ippolito wrote: > I'm having the same issue with that build. > > On Sat, Mar 28, 2015 at 3:42 PM, Alec > wrote: > >> Thanks Mark! But: >> >> % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65 >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> >> Also, `tar xjf` didn't like it very much. Did your upload get cut off? >> The tarball is only 77 Megs. >> >> -A >> >> On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner > > wrote: >> >>> I have built the 7.10.1 bindist for OS X. >>> It is currently sitting on my server at: >>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >>> >>> \O/ >>> >>> I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X >>> . >>> It is based on the above bindist. >>> I should have an ubuntu version of the Platform built by tomorrow. >>> \O/ >>> >>> - Mark >>> >>> *sha256 sums:* >>> c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee >>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >>> 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell >>> Platform 2015.2.0.0 alpha 2 64bit.pkg >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 29 00:19:14 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 17:19:14 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: Verfied that the upload of the ghc bindist was cut short. New upload in progress! I've double checked and the build of Platform, and it's upload is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 29 00:39:14 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 17:39:14 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: Deep apologies to all. The full, correct, and sha-sum verified upload is now up: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 - Mark On Sat, Mar 28, 2015 at 5:19 PM, Mark Lentczner wrote: > Verfied that the upload of the ghc bindist was cut short. > New upload in progress! > > I've double checked and the build of Platform, and it's upload is fine. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From voldermort at hotmail.com Sun Mar 29 12:20:33 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 29 Mar 2015 05:20:33 -0700 (MST) Subject: Proposal: Make Semigroup as a superclass of Monoid Message-ID: <1427631633145-5767835.post@n5.nabble.com> The proposal to make Semigroup a superclass of Monoid was discussed a while ago [1], and the conclusion was to "put this off until the dust has settled from the AMP and FT changes". Now that 7.10 is out, I would like to re-propose. The proposed plan is similar to AMP, but less invasive, as (in my subjective experience) user-defined Monoids are much less common than user-defined Monads. 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid instances, and anything else which forms a Semigroup, will have a Semigroup instance. GHC will issue a warning when it encounters an instance of Monoid which is not an instance of Semigroup. 2. GHC >7.12 will define Monoid as a subclass of Semigroup. Stage 2 could be delayed - or in the extreme case, cancelled - if the warnings following stage 1 indicate that the proposal would cause significant breakage of existing code, although this is not anticipated. The rationale for this change is: 1. Semigroup is a popular package (this is relevant in combination with the following point). 2. Using an existing Monoid as a Semigroup requires redefining it (or WrappedMonoid), leading to much boilerplate and duplication. 3. NonEmpty is often redefined by beginners (or those who don't think it's worth having an extra dependency for). [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html Sent from the Haskell - Libraries mailing list archive at Nabble.com. From michael at snoyman.com Sun Mar 29 12:23:54 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 29 Mar 2015 12:23:54 +0000 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: I'm tentatively +1 on this proposal, presuming we have a solid migration path for the semigroups package (which seems trivial if Edward's on board with this), and barring any solid objections in this discussion. On Sun, Mar 29, 2015 at 3:21 PM Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > Stage 2 could be delayed - or in the extreme case, cancelled - if the > warnings following stage 1 indicate that the proposal would cause > significant breakage of existing code, although this is not anticipated. > > The rationale for this change is: > > 1. Semigroup is a popular package (this is relevant in combination with the > following point). > 2. Using an existing Monoid as a Semigroup requires redefining it (or > WrappedMonoid), leading to much boilerplate and duplication. > 3. NonEmpty is often redefined by beginners (or those who don't think it's > worth having an extra dependency for). > > [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html > > > > -- > View this message in context: http://haskell.1045720.n5. > nabble.com/Proposal-Make-Semigroup-as-a-superclass-of- > Monoid-tp5767835.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Mar 29 12:29:22 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 29 Mar 2015 14:29:22 +0200 (CEST) Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: On Sun, 29 Mar 2015, Jeremy wrote: > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. Good news! Btw. in my package 'non-empty' I use a more general type: NonEmpty f a = Cons a (f a) It allows you to create non-empty Sequences etc. and lists with at least two elements (NonEmpty (NonEmpty []) a). However, inclusion of this type in base or replacing the NonEmpty type from "semigroups" is not necessary, since the more general type can stay in the "non-empty" package and get an Semigroup instance there. > The rationale for this change is: > > 3. NonEmpty is often redefined by beginners (or those who don't think it's > worth having an extra dependency for). And it is often implemented in unnecessarily complicated ways using GADTs or phantom types. From blamario at ciktel.net Sun Mar 29 14:31:23 2015 From: blamario at ciktel.net (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Sun, 29 Mar 2015 10:31:23 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: <55180CBB.50203@ciktel.net> On 03/29/2015 08:20 AM, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. I wasn't aware GHC provided a mechanism to do something like this. If it does, that is great news indeed. Can you point to the GHC extension (or, if not implemented yet, the ticket for creating the extension)? Just to clarify, I'm +1 for the proposal. Even without any GHC magic, I'd be +1 for making Semigroup a superclass of Monoid even if it went through the same code-breaking steps as AMP. From david.feuer at gmail.com Sun Mar 29 14:49:04 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 29 Mar 2015 10:49:04 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <55180CBB.50203@ciktel.net> References: <1427631633145-5767835.post@n5.nabble.com> <55180CBB.50203@ciktel.net> Message-ID: There is no such general extension as far as I know, but the same code that produced warnings about impending AMP in 7.8 should work for this. On Mar 29, 2015 10:31 AM, "Mario Bla?evi?" wrote: > On 03/29/2015 08:20 AM, Jeremy wrote: > >> The proposal to make Semigroup a superclass of Monoid was discussed a >> while >> ago [1], and the conclusion was to "put this off until the dust has >> settled >> from the AMP and FT changes". >> >> Now that 7.10 is out, I would like to re-propose. The proposed plan is >> similar to AMP, but less invasive, as (in my subjective experience) >> user-defined Monoids are much less common than user-defined Monads. >> >> 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid >> instances, and anything else which forms a Semigroup, will have a >> Semigroup >> instance. GHC will issue a warning when it encounters an instance of >> Monoid >> which is not an instance of Semigroup. >> > > I wasn't aware GHC provided a mechanism to do something like this. If > it does, that is great news indeed. Can you point to the GHC extension (or, > if not implemented yet, the ticket for creating the extension)? > > Just to clarify, I'm +1 for the proposal. Even without any GHC magic, > I'd be +1 for making Semigroup a superclass of Monoid even if it went > through the same code-breaking steps as AMP. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Mar 29 15:04:03 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 29 Mar 2015 17:04:03 +0200 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> (Jeremy's message of "Sun, 29 Mar 2015 05:20:33 -0700 (MST)") References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: <87lhifalr0.fsf@gnu.org> On 2015-03-29 at 14:20:33 +0200, Jeremy wrote: > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. +1 From david.feuer at gmail.com Sun Mar 29 15:22:32 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 29 Mar 2015 11:22:32 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <87lhifalr0.fsf@gnu.org> References: <1427631633145-5767835.post@n5.nabble.com> <87lhifalr0.fsf@gnu.org> Message-ID: I like this idea, but I'm not exactly clear on the mechanics. Will mappend move to Semigroup, or <>, or will we get more redundant operations? On Mar 29, 2015 11:04 AM, "Herbert Valerio Riedel" wrote: > On 2015-03-29 at 14:20:33 +0200, Jeremy wrote: > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > > similar to AMP, but less invasive, as (in my subjective experience) > > user-defined Monoids are much less common than user-defined Monads. > > > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > > instances, and anything else which forms a Semigroup, will have a > Semigroup > > instance. GHC will issue a warning when it encounters an instance of > Monoid > > which is not an instance of Semigroup. > > > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > +1 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Mar 29 15:23:19 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 29 Mar 2015 11:23:19 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> <87lhifalr0.fsf@gnu.org> Message-ID: I guess I should get a dog in the fight?I think <> should be the Semigroup method. On Mar 29, 2015 11:22 AM, "David Feuer" wrote: > I like this idea, but I'm not exactly clear on the mechanics. Will mappend > move to Semigroup, or <>, or will we get more redundant operations? > On Mar 29, 2015 11:04 AM, "Herbert Valerio Riedel" wrote: > >> On 2015-03-29 at 14:20:33 +0200, Jeremy wrote: >> > Now that 7.10 is out, I would like to re-propose. The proposed plan is >> > similar to AMP, but less invasive, as (in my subjective experience) >> > user-defined Monoids are much less common than user-defined Monads. >> > >> > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid >> > instances, and anything else which forms a Semigroup, will have a >> Semigroup >> > instance. GHC will issue a warning when it encounters an instance of >> Monoid >> > which is not an instance of Semigroup. >> > >> > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. >> >> +1 >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Mar 29 15:42:52 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 29 Mar 2015 17:42:52 +0200 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: (David Feuer's message of "Sun, 29 Mar 2015 11:23:19 -0400") References: <1427631633145-5767835.post@n5.nabble.com> <87lhifalr0.fsf@gnu.org> Message-ID: <87h9t3ajyb.fsf@gnu.org> On 2015-03-29 at 17:23:19 +0200, David Feuer wrote: > I guess I should get a dog in the fight?I think <> should be the Semigroup > method. +1 From david.feuer at gmail.com Sun Mar 29 15:58:56 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 29 Mar 2015 11:58:56 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <87h9t3ajyb.fsf@gnu.org> References: <1427631633145-5767835.post@n5.nabble.com> <87lhifalr0.fsf@gnu.org> <87h9t3ajyb.fsf@gnu.org> Message-ID: And to forestall the weirdness we ran into with <*> vs. ap, I think GHC 7.12 should give multi-page flashing colored warnings when it sees a Semigroup instance whose definition calls mappend or the non-semigroup version of <>. On Mar 29, 2015 11:42 AM, "Herbert Valerio Riedel" wrote: > On 2015-03-29 at 17:23:19 +0200, David Feuer wrote: > > I guess I should get a dog in the fight?I think <> should be the > Semigroup > > method. > > +1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Sun Mar 29 18:44:52 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 29 Mar 2015 20:44:52 +0200 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: While I like the idea, there are some differences from the Applicative/Monad situation. Most Monads already had an Applicative instance. Monoids, on the other hand, often don't have a Semigroup instance, if only because it lives in a different package. In most cases where I depended on this package, it was because my Semigroup *wasn't* a Monoid. So if I had to guess, this might cause more work for people than the AMP. There are also some details to figure out. There are a couple of name clashes between the semigroups package and Monoid: (<>), as mentioned, but also the newtypes First and Last (with different definitions). How will this all end up, and what is the migration path? I think ideally we'd want (<>) in Semigroup. As for First and Last, as the semigroups docs say, you can get the Monoid versions with Option (First a), but deprecating and removing the Monoid versions will probably cause a lot of breakage. Alternatively, we could have two types with the same name in different modules, but that also doesn't sound ideal, or we could rename the semigroups ones, but that also seems like it would cause a difficult migration. Does anyone have good ideas about this? Regards, Erik On Sun, Mar 29, 2015 at 2:20 PM, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > Stage 2 could be delayed - or in the extreme case, cancelled - if the > warnings following stage 1 indicate that the proposal would cause > significant breakage of existing code, although this is not anticipated. > > The rationale for this change is: > > 1. Semigroup is a popular package (this is relevant in combination with the > following point). > 2. Using an existing Monoid as a Semigroup requires redefining it (or > WrappedMonoid), leading to much boilerplate and duplication. > 3. NonEmpty is often redefined by beginners (or those who don't think it's > worth having an extra dependency for). > > [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html > > > > -- > View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From conrad at metadecks.org Sun Mar 29 19:03:55 2015 From: conrad at metadecks.org (Conrad Parker) Date: Mon, 30 Mar 2015 06:03:55 +1100 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: On 29 March 2015 at 23:20, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. +1 Conrad. From lemming at henning-thielemann.de Sun Mar 29 19:14:37 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 29 Mar 2015 21:14:37 +0200 (CEST) Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: On Sun, 29 Mar 2015, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". Btw. since Monoid is in the Prelude of GHC-7.10, that proposal would also imply that Semigroup will be moved to Prelude, right? If (<>) becomes the method of Semigroup, this would mean that (<>) is also exported by Prelude? From qdunkan at gmail.com Sun Mar 29 19:14:45 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 29 Mar 2015 12:14:45 -0700 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: On Sun, Mar 29, 2015 at 5:20 AM, Jeremy wrote: > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. I think I'm generally in favor, but in my experience is the reverse of this. I have tons of Monoids and only a few Monads. All of my Monads also had Applicative defined because I wanted to use (<$>) and (<*>), however none of my Monoids have Semigroup, because they all have a natural mempty, and there's nothing "extra" in Semigroup that would tempt me to add an instance. So while AMP meant no changes for me, "Semi MP" would definitely force code changes in many places (every 'instance .*Monoid', which is 31 in one project). That said I don't have to worry about backward compatibility so I don't mind. For someone who maintains libraries, they would have to add a dependency on 'semigroup', which is going to pull in a number of other dependencies, but it mostly seems to be stuff people are probably already depending on. Except unordered-containers maybe. From winterkoninkje at gmail.com Sun Mar 29 19:22:18 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 29 Mar 2015 15:22:18 -0400 Subject: wither the Platform In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 10:23 AM, Yitzchak Gale wrote: > Mark Lentczner wrote: >> 1) Abandon the Platform? >> >> 2) Slim the Platform. Pare it back to GHC + base + a smaller set of >> "essential" libs + tools. Keeps a consistent build layout and installation >> mechanism for Haskell. >> >> 3) Re-conceive the Platform. Take a very minimal install approach, coupled >> with close integration with a curated library set that makes it easy to have >> a rich canonical, stable environment. This was the core idea around my "GPS >> Haskell" thoughts from last September - but there would be much to work out >> in this direction. > > I vote for (3) but in a way that it would *not* be much work. > We should definitely do the Platform, but with much *less* work. +1 > The most important reason we need the Platform is as > a default selection of quality basic libraries. We should not abandon > that concept. Curated package sets do not replace that - the > Platform is not just packages that build together. Nor do OS > packagers. The platform is a community-wide set of basic default > packages that are mature, well tested, all work together well, > and stable. > > The second most important role of the Platform is a web site > where you can get a clear picture of how to download and install > a default Haskell installation for your platform, and a simple view > of where we are in the parade of releases. That should also continue. > > The hardest work of the Platform was its role as a way to bootstrap a > Haskell installation. That is what made it so hard for HP to keep up > with GHC releases, and what consequently gave people the impression > that HP is always old. That work doesn't need to be done as part of the > Platform anymore. We should leverage other good work people are > doing to create installers, and stop doing it as part of the HP process. > > The most important part of an HP release should be a cabal package > that provides the packages in the platform, at the right versions, with > a specification of the recommended GHC version as a pre-requisite. > > Perhaps we can also provide an HP-branded slick installer for some > platforms that does everything in one click, built as a thin wrapper of > some existing installer. But that should not delay the official release > of an HP version. It's just a nice-to-have extra. > > Once we pare down the work needed for an HP release, we should > release new versions of HP quite often - *more* often than GHC > releases, not less often. > > Another thing we should fix is the (now false) impression that HP > gets in the way of installing other packages and versions due to > cabal hell. We should make "require-sandbox" the default setting > in the cabal config file. I would go further - I would add a cabal > feature to create a sandbox automatically unless "--user" or > "--global" is specified explicitly. I would make "foo installed" a > default constraint (that is easy to override) for all platform packages, > which solves virtually all cabal hell problems (assuming you are > using a sandbox) and will not keep things old if we release often. One of the original goals of the HP was to try and reduce cabal hell issues, but we've since seen a great deal of work in trying to solve those problems by other means. Similarly, one of the original goals was to improve Windows installation, but that too seems to have moved on. With these changes in the landscape, it's no wonder the HP doesn't seem to have much public uptake these days. As present, I think we do still need something like HP, albeit recast to fit the new landscape. The goals of Stackage and LTS are quite different, and thus they cannot fill the role that HP does/did. ... For me, the HP has served a couple roles. First (in no particular order): to serve as a one-click install for getting Haskell up and running on a new computer. Second: to serve as a stable and coherent snapshot of the Haskell ecosystem. This latter purpose seems, imo, to be the more important one going forward. In the enterprise setting ?including the enterprising FOSS community? it's important to have checkpoints as a way of tracking backwards compatibility. While most developers focus on getting the shiniest newest things, this backwards support is extremely important both for maintaining infrastructures and for introducing new folks to the community; for both these groups, the newest and shiniest things may not be easily available/usable due to economic concerns. The "preserve compatibility with the last X versions" model works well for dependencies like GHC, but it's not always clear (in retrospect) which versions of hackage libraries were the contemporary/standard versions corresponding to each GHC version. Thus, providing these sorts of checkpoints is a necessary part of community building? for commercial enterprise, FOSS enterprise, and newcomers alike. Now that we have our foot in the door with various distros, the goal of providing checkpoints can also help to satisfy the one-click install goal, since the checkpoint provides distro managers guidance on how to support a coherent snapshot of the crucial/main libraries needed to get up and running. (Also, this could potentially provide an avenue for reducing the work involved in releasing the HP; that is, by relying on distros to deal with the distribution aspect, we could focus more on just building/testing the configurations for each release.) ... As mentioned elsewhere in the thread, the outdatedness image of the HP is definitely a problem. The salient solution here is to try and release more often than we do now. Of course, with the amount of work the HP currently takes for each release, that's not really tenable. When the HP started we all knew it'd be a bunch of work, but that work seemed like a good idea at the time. Now that the goalposts have moved, that work seems more like an unnecessary burden. So, what could the HP offer today which would be worth the work it takes to do so? -- Live well, ~wren From winterkoninkje at gmail.com Sun Mar 29 20:08:55 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 29 Mar 2015 16:08:55 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Wed, Mar 25, 2015 at 12:43 AM, Manuel M T Chakravarty wrote, In reply to Gershom B : > You are talking about a specific kind of new users. These new users want to install a web stack or similar ? i.e., they need tons of packages. These people may be new to Haskell, but I reckon they are otherwise power users. > > I?m talking about somebody picking up Learn you a Haskell and wanting to write Hello World. Why should they care about sandboxes? Who cares if they mess up their installation by installing the wrong package. They can always nuke it and install it again. That?s a much simpler story. > > Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn?t use sandboxes either.) > > [...] > > The mistake here is to try to make this a one-size-fits all. I honestly don?t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. > > If somebody gets sufficiently hooked on Haskell to want to start a bigger project, then they will have the patience for a more elaborate story (and wait for cabal install for a few hours to do its job). > > The point is that one-size-fits-all is inherently unfriendly to novices. A novice needs something simple with as few options as possible, whereas a power user wants flexibility and customisability. A minimal installer with sandboxes gives you the latter, but it comes at the expense of simplicity, which makes is unfriendly to novices. I just want to chime in and +1 to this. As both a power-user and an educator (of multiple languages including: Haskell, Agda, Isabelle, Coq), the importance of easing installation for novices cannot be understated. One-size-fits-all is extremely unfriendly to novices. Requiring the use of a novel packaging/distribution system is extremely unfriendly to novices. Requiring compilation of dependencies is extremely unfriendly to novices. Adding choice to users ill-equipped to choose is extremely unfriendly; and novices are, by definition, ill-equipped to make these choices. Relying on cabal-install and hackage is great for active developers, but developers have completely different needs than novices. IMO, anyone who requires a full web development stack is not a novice. In all my years of using Haskell, the *only* time I've ever run into cabal hell issues ?and the only horror stories I've heard personally? have been about (1) webdev frameworks, or (2) the now-passed chaos of the mtl/transformers switchover. -- Live well, ~wren From mark.lentczner at gmail.com Mon Mar 30 00:24:23 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Mar 2015 17:24:23 -0700 Subject: Platform 2015.2.0.0 Alpha 2 for debian based systems Message-ID: I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for generic debian linux systems. It includes GHC 7.10.2, using the generic linux bindist. This is a tarball, not a package. Installation instructions: cd / sudo tar xvf ...downloaded-tarfile... sudo /usr/local/haskell/ghc-7.10.1-x86-64/bin/activate-hs Notes: - Built on Ubuntu 14.04LTS - Needs the following packages installed: build-essential libbsd-dev libgmp-dev libtinfo-dev zlib1g-dev - The OpenGL packages need the OpenGL libs, which on a non-GUI system like a server can be gotten by installing: freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregweber.info Mon Mar 30 00:33:49 2015 From: greg at gregweber.info (Greg Weber) Date: Sun, 29 Mar 2015 17:33:49 -0700 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid instances, and anything else which forms a Semigroup, will have a Semigroup instance. GHC will issue a warning when it encounters an instance of Monoid which is not an instance of Semigroup. There is going to be some push-back on this proposal from those that point out the lack of mempty makes Semigroup less rigorous that a Monoid. That concept can create a debate around what is "anything else which forms a semigroup". I would try to amend the proposal to something much more specific. Here is how I have used Semigroup 1) a structure that is already a Monoid 2) a structure that is a non-empty form of a Monoid 3) a structure where mempty is not constant but a function of the element you would concatenate it to An example of 3) is concatenating bounding boxes. A zeroed box is certainly an empty box, but it will create a larger box when concatenated with an existing box.The identity concatenation of the current bounding box is always the current bounding box. What other structures do you use Semigroup for? Are there structures in base where there would be a debate about adding an instance? Can we come up with rules for when a Semigroup instance should be added to base? On Sun, Mar 29, 2015 at 5:20 AM, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > Stage 2 could be delayed - or in the extreme case, cancelled - if the > warnings following stage 1 indicate that the proposal would cause > significant breakage of existing code, although this is not anticipated. > > The rationale for this change is: > > 1. Semigroup is a popular package (this is relevant in combination with the > following point). > 2. Using an existing Monoid as a Semigroup requires redefining it (or > WrappedMonoid), leading to much boilerplate and duplication. > 3. NonEmpty is often redefined by beginners (or those who don't think it's > worth having an extra dependency for). > > [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 30 00:44:51 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 29 Mar 2015 20:44:51 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: my one concern is that we'd be force to give all the various map data structures out there a left biased "First" style semigroup instance if we keep the current default monoid instances that containers and list-tries provide for historical reasons. and at least in the applications i write, i want the semigroup that merges those keys. On Sun, Mar 29, 2015 at 3:14 PM, Evan Laforge wrote: > On Sun, Mar 29, 2015 at 5:20 AM, Jeremy wrote: > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > > similar to AMP, but less invasive, as (in my subjective experience) > > user-defined Monoids are much less common than user-defined Monads. > > I think I'm generally in favor, but in my experience is the reverse of > this. I have tons of Monoids and only a few Monads. All of my Monads > also had Applicative defined because I wanted to use (<$>) and (<*>), > however none of my Monoids have Semigroup, because they all have a > natural mempty, and there's nothing "extra" in Semigroup that would > tempt me to add an instance. So while AMP meant no changes for me, > "Semi MP" would definitely force code changes in many places (every > 'instance .*Monoid', which is 31 in one project). > > That said I don't have to worry about backward compatibility so I > don't mind. For someone who maintains libraries, they would have to > add a dependency on 'semigroup', which is going to pull in a number of > other dependencies, but it mostly seems to be stuff people are > probably already depending on. Except unordered-containers maybe. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Mon Mar 30 00:49:32 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 29 Mar 2015 20:49:32 -0400 Subject: ANN: logfloat 0.13.3 Message-ID: -------------------------------------------- -- logfloat 0.13.3 -------------------------------------------- This package provides a type for storing numbers in the log-domain, primarily useful for preventing underflow when multiplying many probabilities as in HMMs and other probabilistic models. The package also provides modules for dealing with floating numbers correctly. This version drops support for Hugs and GHC < 7.8. Nothing major has changed, so they should still work; it's just that they're no longer officially supported. Thus, this version of the library provides a transitional point between backwards compatability and adding new features (see below). -------------------------------------------- -- Changes since 0.12.1 (2010-03-19) -------------------------------------------- * Monomorphized logFloat, logToLogFloat, fromLogFloat, and logFromLogFloat: that is, they all take/return Double now. The change was made to help reduce the need for explicit type signatures. It shouldn't really affect most users, since it seems noone was really making use of the polymorphism provided by previous versions. To get the previous behavior back, just explicitly add calls to realToFrac wherever necessary. * Fixed some instances to get them to compile under the new role-based type system of GHC 7.10 * Cleaned up various extraneous rewrite rules, specializations, etc * Added the functions sum, product, and pow. Both sum and product preserve more precision than the fold-based definitions in the Prelude. Moreover, sum is _much_ faster than the Prelude version, since it only requires crossing the log/exp boundary n+1 times, instead of 2*(n-1) times. The only downside is that sum requires two passes over the input and thus is not amenable to list fusion. -------------------------------------------- -- Upcoming changes (0.14+) -------------------------------------------- * Since the Data.Number.RealToFrac module is no longer required by any of the others, it will probably be forked off to a separate package in order to improve portability of the rest of the package by removing the need for MPTCs. * There's long been clamoring for adding a vector:Data.Vector.Unboxed.Unbox instance. I've been reluctant to add such an instance due to wanting to retain backwards compatibility and portability. Having dropped support for Hugs and older versions of GHC, I'm now willing to add them in. The logfloat library is conceptually quite simple, and thus to whatever extent possible I'd still like to retain portability to non-GHC compilers. So if you are interested in using logfloat with another compiler/interpreter but run into problems (e.g., due to the type families required by the vector library), please get in touch and I'll try to get things to work. -------------------------------------------- -- Compatibility / Portability -------------------------------------------- The package is compatible with GHC 7.8.3 and 7.10.1. It may still compile with older versions of GHC (or even Hugs!), however they are no longer officially supported. The package is not compatible with nhc98 and Yhc because Data.Number.RealToFrac uses MPTCs. However, that module is no longer required by any others, and all the other modules should be compatible with these compilers. Thus, it should be fairly easy to port. If you do so, please let me know and I'll try to incorporate support for them. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/logfloat Darcs: http://code.haskell.org/~wren/logfloat/ Haddock (Darcs version): http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/ -- Live well, ~wren From winterkoninkje at gmail.com Mon Mar 30 00:58:09 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 29 Mar 2015 20:58:09 -0400 Subject: ANN: stm-chans 3.0.0.3 Message-ID: -------------------------------------------- -- stm-chans 3.0.0.3 -------------------------------------------- The stm-chans package offers a collection of channel types, similar to Control.Concurrent.STM.{TChan,TQueue} but with additional features. -------------------------------------------- -- Changes since 3.0.0 (2013-05-29) -------------------------------------------- Cleaned up the header gunk to compile cleanly under GHC 7.10. No actual code has been altered. -------------------------------------------- -- Long description -------------------------------------------- In particular stm-chans offers the following data types: * Control.Concurrent.STM.TBChan: Bounded FIFO channels. When the channel is full, writers will block/retry. This ensures that the writers do not get too far ahead of the readers, which helps to make sure that memory and cpu resources are used responsibly. * Control.Concurrent.STM.TMChan: Closeable FIFO channels. * Control.Concurrent.STM.TMQueue: Closeable FIFO queues. Like TChan (Maybe a) but with a monotonicity guarantee that once Nothing is returned all future reads will be Nothing as well. * Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels. * Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues. Combines the capabilities of TBChan and TMChan. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/stm-chans Darcs: http://community.haskell.org/~wren/stm-chans Haddock (Darcs version): http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans -- Live well, ~wren From winterkoninkje at gmail.com Mon Mar 30 01:12:48 2015 From: winterkoninkje at gmail.com (wren romano) Date: Sun, 29 Mar 2015 21:12:48 -0400 Subject: ANN: unification-fd 0.10.0 Message-ID: -------------------------------------------- -- unification-fd 0.10.0 -------------------------------------------- The unification-fd package offers generic functions for single-sorted first-order structural unification (think of programming in Prolog, or of the metavariables in type inference)[1][2]. The library *is* sufficient for implementing higher-rank type systems a la [Peyton Jones, Vytiniotis, Weirich, Shields], but bear in mind that unification variables are the metavariables of type inference--- not the type-variables. As of this version, the library is also sufficient for implementing (non-recursive) feature structure unification. An effort has been made to make the package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -------------------------------------------- -- Changes since 0.8.0 (2012-07-11) -------------------------------------------- * (0.8.1) Added Functor, Foldable, and Traversable instances for COntrol.Unification.Types.UnificationFailure. Thanks Graham Rogers. * (0.9.0) Changed the fundeps on BindingMonad and RankedBindingMonad so that things compule under GHC 7.8.2 * (0.9.0) eta-expanded the rewrite rules in Data.Functor.Fixedpoint so that GHC 7.8 no longer gives warnings about not firing due to (.) possibly being inlined first * Cleaned things up to compile cleanly for GHC 7.10 * For EitherK and MaybeK, liberalized the instances to only require Applicative instead of Monad wherever possible. * Completely revamped the old UnificationFailure data type as the new UFailure data type and Fallible type class. This was necessary to clean up some deprecation warnings about using Control.Monad.Error, to remove the hack of needing an UnknownError constructor, and to make the data type for representing failures more extensible. -------------------------------------------- -- Description -------------------------------------------- The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type Term = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked, or Nothing if this level doesn't match. Each subterm can be separately marked as being resolved, Left xy, or as requiring further unification, Right(x,y). class (Traversable t) => Unifiable t where zipMatch :: t a -> t a -> Maybe (t (Either a (a, a))) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the modified path compression as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -------------------------------------------- -- Notes and limitations -------------------------------------------- [1] At present the library does not appear amenable for implementing higher-rank unification itself; i.e., for higher-ranked metavariables, or higher-ranked logic programming. To be fully general we'd have to abstract over which structural positions are co/contravariant, whether the unification variables should be predicative or impredicative, as well as the isomorphisms of moving quantifiers around. It's on my todo list, but it's certainly non-trivial. If you have any suggestions, feel free to contact me. [2] At present it is only suitable for single-sorted (aka untyped) unification, a la Prolog. In the future I aim to support multi-sorted (aka typed) unification, however doing so is complicated by the fact that it can lead to the loss of MGUs; so it will likely be offered as an alternative to the single-sorted variant, similar to how the weighted path-compression is currently offered as an alternative. [3] With the exception of fundeps which are notoriously difficult to implement. However, they are supported by Hugs and GHC 6.6, so I don't feel bad about requiring them. Once the API stabilizes a bit more I plan to release a unification-tf package which uses type families instead, for those who feel type families are easier to implement or use. There have been a couple requests for unification-tf, so I've bumped it up on my todo list. -------------------------------------------- -- References -------------------------------------------- Luca Cardelli (1987) /Basic polymorphic typechecking/. Science of Computer Programming, 8(2):147--172. Atze Dijkstra, Arie Middelkoop, S. Doaitse Swierstra (2008) /Efficient Functional Unification and Substitution/, Technical Report UU-CS-2008-027, Utrecht University. Simon Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields /Practical type inference for arbitrary-rank types/, to appear in the Journal of Functional Programming. (Draft of 31 July 2007.) Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman, and Amr Sabry (2005) /Backtracking, Interleaving, and/ /Terminating Monad Transformers/, ICFP. Tim Sheard (2001) /Generic Unification via Two-Level Types/ /and Paramterized Modules/, Functional Pearl, ICFP. Tim Sheard & Emir Pasalic (2004) /Two-Level Types and/ /Parameterized Modules/. JFP 14(5): 547--587. This is an expanded version of Sheard (2001) with new examples. Wouter Swierstra (2008) /Data types a la carte/, Functional Pearl. JFP 18: 423--436. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unification-fd Darcs: http://community.haskell.org/~wren/unification-fd Haddock (Darcs version): http://community.haskell.org/~wren/unification-fd/dist/doc/html/unification-fd -- Live well, ~wren From mark.lentczner at gmail.com Mon Mar 30 01:13:08 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Mar 2015 18:13:08 -0700 Subject: Platform 2015.2.0.0 Alpha 2 for debian based systems In-Reply-To: References: Message-ID: > > I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for > generic debian linux systems. > It includes GHC 7.10.2 > Ooops - GHC 7.10.1 - of course! -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 30 01:57:46 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 29 Mar 2015 21:57:46 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: Greg, the proposal is for Semigroup s => Monoid s, not for Monoid s => Semigroup s , which is what i believe you're reading the proposal to say. a large number of statistical aggregatory and analytical data structures are semigroups but emphatically not monoids because they lack the notion of a zero element! over the past 8 months alone i've probably 5-10 different data structures for statistical ingestion that were semigroups but not monoids. point being, semigroups are well defined mathematical objects, and i deal with many many things that are semigroups and not monoids, especially in data analysis application domains. I can provide a few example later this week if you want. On Sun, Mar 29, 2015 at 8:33 PM, Greg Weber wrote: > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > There is going to be some push-back on this proposal from those that point > out the lack of mempty makes Semigroup less rigorous that a Monoid. That > concept can create a debate around what is "anything else which forms a > semigroup". > I would try to amend the proposal to something much more specific. > Here is how I have used Semigroup > > 1) a structure that is already a Monoid > 2) a structure that is a non-empty form of a Monoid > 3) a structure where mempty is not constant but a function of the element > you would concatenate it to > > An example of 3) is concatenating bounding boxes. A zeroed box is > certainly an empty box, but it will create a larger box when concatenated > with an existing box.The identity concatenation of the current bounding box > is always the current bounding box. > > What other structures do you use Semigroup for? > Are there structures in base where there would be a debate about adding an > instance? > Can we come up with rules for when a Semigroup instance should be added to > base? > > On Sun, Mar 29, 2015 at 5:20 AM, Jeremy wrote: > >> The proposal to make Semigroup a superclass of Monoid was discussed a >> while >> ago [1], and the conclusion was to "put this off until the dust has >> settled >> from the AMP and FT changes". >> >> Now that 7.10 is out, I would like to re-propose. The proposed plan is >> similar to AMP, but less invasive, as (in my subjective experience) >> user-defined Monoids are much less common than user-defined Monads. >> >> 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid >> instances, and anything else which forms a Semigroup, will have a >> Semigroup >> instance. GHC will issue a warning when it encounters an instance of >> Monoid >> which is not an instance of Semigroup. >> >> 2. GHC >7.12 will define Monoid as a subclass of Semigroup. >> >> Stage 2 could be delayed - or in the extreme case, cancelled - if the >> warnings following stage 1 indicate that the proposal would cause >> significant breakage of existing code, although this is not anticipated. >> >> The rationale for this change is: >> >> 1. Semigroup is a popular package (this is relevant in combination with >> the >> following point). >> 2. Using an existing Monoid as a Semigroup requires redefining it (or >> WrappedMonoid), leading to much boilerplate and duplication. >> 3. NonEmpty is often redefined by beginners (or those who don't think it's >> worth having an extra dependency for). >> >> [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html >> >> >> >> -- >> View this message in context: >> http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html >> Sent from the Haskell - Libraries mailing list archive at Nabble.com. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Mon Mar 30 03:16:33 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 29 Mar 2015 22:16:33 -0500 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: <20150330031633.GA28985@mintha> On 29/03/2015 at 05:20:33 -0700, Jeremy wrote: > 1. GHC 7.12 will include Semigroup and NonEmpty in base. +1 for Semigroup at least. NonEmpty is simply the cofree comonad of Maybe, so I think we ought to define it either as such or to be compatibly redefinitile as such, e.g. now: data NonEmpty a = a .: Maybe (NonEmpty a) so potentially later: data Cofree f a = a .: f (Cofree f a) type NonEmpty = Cofree Maybe as otherwise we shall have various code using nonsame isomorphic types which one must convert or coerce between for no good reason. +1 for NonEmpty if so defined, -1 otherwise. > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. +1 On 29/03/2015 at 11:23:19 -0400, David Feuer wrote: > I guess I should get a dog in the fight?I think <> should be the Semigroup method. +1 From cheecheeo at gmail.com Mon Mar 30 03:39:09 2015 From: cheecheeo at gmail.com (John Alfred Nathanael Chee) Date: Sun, 29 Mar 2015 20:39:09 -0700 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <20150330031633.GA28985@mintha> References: <1427631633145-5767835.post@n5.nabble.com> <20150330031633.GA28985@mintha> Message-ID: Jeremy, Do you propose: Monoid a => Monoid (Maybe a) be changed to: Semigroup a => Monoid (Maybe a) as the documentation indicates? +1, but I think there are some technicalities that I think would benefit from a more concrete proposal including as a patch or hackage analysis. On Sun, Mar 29, 2015 at 8:16 PM, M Farkas-Dyck wrote: > On 29/03/2015 at 05:20:33 -0700, Jeremy wrote: > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. > > +1 for Semigroup at least. > > NonEmpty is simply the cofree comonad of Maybe, so I think we ought to > define it either as such or to be compatibly redefinitile as such, e.g. > > now: > data NonEmpty a = a .: Maybe (NonEmpty a) > > so potentially later: > data Cofree f a = a .: f (Cofree f a) > type NonEmpty = Cofree Maybe > > as otherwise we shall have various code using nonsame isomorphic types > which one must convert or coerce between for no good reason. > > +1 for NonEmpty if so defined, -1 otherwise. > > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > +1 > > On 29/03/2015 at 11:23:19 -0400, David Feuer wrote: > > I guess I should get a dog in the fight?I think <> should be the > Semigroup method. > > +1 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Love in Jesus Christ, John Alfred Nathanael Chee http://www.biblegateway.com/ http://web.cecs.pdx.edu/~chee/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Mon Mar 30 05:05:56 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Mon, 30 Mar 2015 14:05:56 +0900 Subject: traverse_ Message-ID: > Hi, > I have just installed GHC 7.10.1. I'm a little bit surprised because > 'traverse_' is not exported from Prelude. But 'traverse' is exported. > Is this intentional? > I expected that I can forget xxxM, xxxM_, xxxA, and xxxA_ functions > with GHC 7.10.1. I want to use 'traverse_' instead of 'mapM_'. > --Kazu I found out that (<>) (in Data.Monoid) is missing, also. It would be nice to reexamine Prelude to export things we want to export. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Mar 30 07:54:36 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 30 Mar 2015 09:54:36 +0200 Subject: traverse_ In-Reply-To: (Fumiaki Kinoshita's message of "Mon, 30 Mar 2015 14:05:56 +0900") References: Message-ID: <87y4mehqdf.fsf@gnu.org> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: [...] > I found out that (<>) (in Data.Monoid) is missing, also. It would be nice > to reexamine Prelude to export things we want to export. Fwiw, (<>) was actually left-out as it wasn't required (it's just a an alias for `mappend`), *and* to keep our options open (or at least not make it more difficult) in terms of possible migration-plans available for the case we'd be moving 'Semigroup' to base/Prelude at some point in the future. From dominic at steinitz.org Mon Mar 30 07:55:04 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 30 Mar 2015 07:55:04 +0000 (UTC) Subject: =?utf-8?b?TGlicmFyeV9zdWJtaXNzaW9ucw==?= and Call for Maintainers References: Message-ID: Edward Kmett gmail.com> writes: > * random > > We've had some truly excellent work done over the last couple of > years on how to deal with "splitting" a random number generator in a > cryptographically sound manner. I spent some time cleaning up a few > outstanding issues for this package personally over the summer, but > have not had nearly enough time to devote to the issue of how to > integrate the outcome of the recent research on splitting, while > simultaneously caring about performance and soundness. I finally managed to get some time to start looking at this. I have created a ticket here https://github.com/haskell/random/issues/25 Please add comments and any information you think Carter and I might find helpful. I discovered the package has some benchmarks that are 3+ years old. At the moment, I am not sure what they are telling me. If anyone has any background / views please chip in. Dominic. From lemming at henning-thielemann.de Mon Mar 30 08:38:56 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 30 Mar 2015 10:38:56 +0200 (CEST) Subject: ANN: logfloat 0.13.3 In-Reply-To: References: Message-ID: On Sun, 29 Mar 2015, wren romano wrote: > -------------------------------------------- > -- logfloat 0.13.3 > -------------------------------------------- > > This package provides a type for storing numbers in the log-domain, > primarily useful for preventing underflow when multiplying many > probabilities as in HMMs and other probabilistic models. The package > also provides modules for dealing with floating numbers correctly. I am currently working on http://hub.darcs.net/thielema/hmm-hmatrix It does not need log-numbers because it normalizes all temporary results. This way I can use fast hmatrix operations. Would normalization also be a solution for other probabilistic models? From merijn at inconsistent.nl Mon Mar 30 09:23:56 2015 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Mon, 30 Mar 2015 11:23:56 +0200 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> <20150330031633.GA28985@mintha> Message-ID: <03FDCB37-EEC8-4746-B46D-FB6073936BCD@inconsistent.nl> -2 from me. Not because I oppose Semigroup as a superclass of Monoid, but because of brittle migration path. I would much rather put the resurrection of DefaultSuperclassInstances [1], IntrinsicSuperclasses [2], or some new proposal on the roadmap that would allow us to more easily refactor and update the typeclass hierarchy without breaking everything all the time. Cheers, Merijn [1] - https://ghc.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances [2] - https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses > On 30 Mar 2015, at 5:39, John Alfred Nathanael Chee wrote: > > Jeremy, > > Do you propose: > > Monoid a => Monoid (Maybe a) > > be changed to: > > Semigroup a => Monoid (Maybe a) > > as the documentation indicates? > > +1, but I think there are some technicalities that I think would benefit from a more concrete proposal including as a patch or hackage analysis. > > On Sun, Mar 29, 2015 at 8:16 PM, M Farkas-Dyck wrote: > On 29/03/2015 at 05:20:33 -0700, Jeremy wrote: > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. > > +1 for Semigroup at least. > > NonEmpty is simply the cofree comonad of Maybe, so I think we ought to define it either as such or to be compatibly redefinitile as such, e.g. > > now: > data NonEmpty a = a .: Maybe (NonEmpty a) > > so potentially later: > data Cofree f a = a .: f (Cofree f a) > type NonEmpty = Cofree Maybe > > as otherwise we shall have various code using nonsame isomorphic types which one must convert or coerce between for no good reason. > > +1 for NonEmpty if so defined, -1 otherwise. > > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > +1 > > On 29/03/2015 at 11:23:19 -0400, David Feuer wrote: > > I guess I should get a dog in the fight?I think <> should be the Semigroup method. > > +1 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > Love in Jesus Christ, John Alfred Nathanael Chee > http://www.biblegateway.com/ > http://web.cecs.pdx.edu/~chee/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- 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 dominic at steinitz.org Mon Mar 30 10:42:07 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 30 Mar 2015 11:42:07 +0100 Subject: Hidden Markov Models Message-ID: <8CD47B99-F0D2-4745-A49D-93DA6BF03686@steinitz.org> > I am currently working on > http://hub.darcs.net/thielema/hmm-hmatrix > > It does not need log-numbers because it normalizes all temporary results. > This way I can use fast hmatrix operations. Would normalization also be a > solution for other probabilistic models? I assume these are models with finite state spaces? FYI I uploaded a Kalman filter https://github.com/idontgetoutmuch/Kalman which is also a HMM. I feel we should be able to abstract over the Markov transition kernel to describe the model without caring whether the state space is continuous or discrete but that it is about as much thinking I have done on the subject. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 30 18:21:39 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 30 Mar 2015 14:21:39 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: <1427631633145-5767835.post@n5.nabble.com> References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: Consider me a +1 on this. There are some unmentioned caveats here: * We may want/need a slightly longer release schedule. * `Monoid` is in the Prelude, so this would drag `Semigroup` into the Prelude. I see two ways to proceed. The long path: A straw-man fleshed out version of your proposal that addresses the "sudden change to Prelude" issues some folks have would be: 7.12: Move Data.Semigroup and Data.List.NonEmpty into base. Add a warning about definitions of an operator named (<>) that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of (<>) as they'll break in 7.14. 7.14: Move Semigroup and (<>) into the Prelude in 7.14. Add a warning about missing Semigroup instances for any Monoid instance at all. 7.16: Make Semigroup a superclass of Monoid. Fix the instance Semigroup a => Monoid (Maybe a). Alternate long path: Simplify the warnings. Simply warn about any missing Semigroup instance when you define a Monoid instance in 7.12, so the 7.14 changes become simply a migration into Prelude. The downside is that people would now get a warning that force them to import a module that will be redundant in the next release. =/ The short path: Collapse the first two steps into one step, but this means that nobody gets any warning of new names coming into the Prelude. On the other hand this would get us all the way to done by 7.14. On one hand, the first order consequence the amount of breakage caused by adding Semigroup to Prelude and taking (<>) is almost entirely confined to a handful of pretty printing libraries -- and we already broke those same libraries by taking (<$>). Sadly a second order consequence is that folks import Data.Monoid to get (<>) today, and this would change to demanding a Semigroup constraint, so the fused release would actually cause almost as much breakage as doing it all in one go, among anybody that actually uses the (<>) in Data.Monoid. I have a preference for one of the long paths, as they at no point break someone without warning. We could run a poll to see which folks would prefer. Having default superclass instance machinery would go a long way towards simplifying this story, but I think we've held up all progress on almost everything for the better part of two decades waiting for that situation to resolve without progress. -Edward Kmett On Sun, Mar 29, 2015 at 8:20 AM, Jeremy wrote: > The proposal to make Semigroup a superclass of Monoid was discussed a while > ago [1], and the conclusion was to "put this off until the dust has settled > from the AMP and FT changes". > > Now that 7.10 is out, I would like to re-propose. The proposed plan is > similar to AMP, but less invasive, as (in my subjective experience) > user-defined Monoids are much less common than user-defined Monads. > > 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid > instances, and anything else which forms a Semigroup, will have a Semigroup > instance. GHC will issue a warning when it encounters an instance of Monoid > which is not an instance of Semigroup. > > 2. GHC >7.12 will define Monoid as a subclass of Semigroup. > > Stage 2 could be delayed - or in the extreme case, cancelled - if the > warnings following stage 1 indicate that the proposal would cause > significant breakage of existing code, although this is not anticipated. > > The rationale for this change is: > > 1. Semigroup is a popular package (this is relevant in combination with the > following point). > 2. Using an existing Monoid as a Semigroup requires redefining it (or > WrappedMonoid), leading to much boilerplate and duplication. > 3. NonEmpty is often redefined by beginners (or those who don't think it's > worth having an extra dependency for). > > [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclass-of-Monoid-tp5767835.html > Sent from the Haskell - Libraries mailing list archive at Nabble.com. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Mar 30 18:25:28 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 30 Mar 2015 14:25:28 -0400 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: There was some handwringing recently about the fact that we have two random packages in the platform. You may also want to look at what tf-random is doing, and see if it would make sense to try to merge the two packages. Perhaps reach out to Micha? Pa?ka? It seems a shame to have two classes for Random lying around with subtly different semantics. -Edward On Mon, Mar 30, 2015 at 3:55 AM, Dominic Steinitz wrote: > Edward Kmett gmail.com> writes: > > > * random > > > > We've had some truly excellent work done over the last couple of > > years on how to deal with "splitting" a random number generator in a > > cryptographically sound manner. I spent some time cleaning up a few > > outstanding issues for this package personally over the summer, but > > have not had nearly enough time to devote to the issue of how to > > integrate the outcome of the recent research on splitting, while > > simultaneously caring about performance and soundness. > > I finally managed to get some time to start looking at this. I have > created a ticket here > > https://github.com/haskell/random/issues/25 > > Please add comments and any information you think Carter and I might > find helpful. > > I discovered the package has some benchmarks that are 3+ years old. At > the moment, I am not sure what they are telling me. If anyone has any > background / views please chip in. > > Dominic. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Mar 30 18:51:52 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 30 Mar 2015 20:51:52 +0200 (CEST) Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: On Mon, 30 Mar 2015, Edward Kmett wrote: > Collapse the first two steps into one step, but this means that nobody gets any warning of new names coming > into the Prelude. On the other hand this would get us all the way to done by 7.14. On one hand, the first > order consequence the amount of breakage caused by adding Semigroup to Prelude and taking (<>) is almost > entirely confined to a handful of pretty printing libraries -- and we already broke those same libraries by > taking (<$>). Btw. hmatrix is another prominent package defining (<>) for matrix and related multiplications. From qdunkan at gmail.com Mon Mar 30 18:57:21 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 30 Mar 2015 11:57:21 -0700 Subject: Library_submissions and Call for Maintainers In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 11:25 AM, Edward Kmett wrote: > You may also want to look at what tf-random is doing I don't see how anyone could know wtf random is doing, it seems completely unpredictable. ... sorry couldn't resist From ekmett at gmail.com Mon Mar 30 19:09:46 2015 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 30 Mar 2015 15:09:46 -0400 Subject: Proposal: Make Semigroup as a superclass of Monoid In-Reply-To: References: <1427631633145-5767835.post@n5.nabble.com> Message-ID: That definitely pushes me towards one of the "long" adoption paths. Here adding a Semigroup instance for Matrix actually works to get the same symbol, but it has a different fixity (infixr 8). Same with (<>) in the pretty printing libraries (infixl 6). In Data.Monoid and Data.Semigroup we have infixr 6 <> -Edward On Mon, Mar 30, 2015 at 2:51 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 30 Mar 2015, Edward Kmett wrote: > > Collapse the first two steps into one step, but this means that nobody >> gets any warning of new names coming >> into the Prelude. On the other hand this would get us all the way to done >> by 7.14. On one hand, the first >> order consequence the amount of breakage caused by adding Semigroup to >> Prelude and taking (<>) is almost >> entirely confined to a handful of pretty printing libraries -- and we >> already broke those same libraries by >> taking (<$>). >> > > Btw. hmatrix is another prominent package defining (<>) for matrix and > related multiplications. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Tue Mar 31 03:33:30 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Tue, 31 Mar 2015 12:33:30 +0900 Subject: traverse_ In-Reply-To: <87y4mehqdf.fsf@gnu.org> References: <87y4mehqdf.fsf@gnu.org> Message-ID: Well, I see. It'd be nice. That aside, the absence of traverse_ doesn't seem to be intended (even the documentation for mapM_ says "mapM_ is just traverse_"!) 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : > On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: > > [...] > > > I found out that (<>) (in Data.Monoid) is missing, also. It would be nice > > to reexamine Prelude to export things we want to export. > > Fwiw, (<>) was actually left-out as it wasn't required (it's just a an > alias for `mappend`), *and* to keep our options open (or at least not > make it more difficult) in terms of possible migration-plans available > for the case we'd be moving 'Semigroup' to base/Prelude at some point in > the future. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Tue Mar 31 04:27:32 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Tue, 31 Mar 2015 17:27:32 +1300 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: Both traverse and mapM_ are in the GHC 7.10 Prelude for specific reasons. mapM_ was already in the Prelude before the AMP proposal, so it was grandfathered in. traverse is required for writing Traversable instances. While it would be useful to have it in the Prelude, traverse_ doesn't fit either of the motivations above. So I think its omission is intended here. On Tue, Mar 31, 2015 at 4:33 PM, Fumiaki Kinoshita wrote: > Well, I see. It'd be nice. > > That aside, the absence of traverse_ doesn't seem to be intended (even the > documentation for mapM_ says "mapM_ is just traverse_"!) > > 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : >> >> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >> >> [...] >> >> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >> > nice >> > to reexamine Prelude to export things we want to export. >> >> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >> alias for `mappend`), *and* to keep our options open (or at least not >> make it more difficult) in terms of possible migration-plans available >> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >> the future. >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- https://lambda.xyz From hvr at gnu.org Tue Mar 31 09:38:52 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 31 Mar 2015 11:38:52 +0200 Subject: traverse_ In-Reply-To: (Chris Wong's message of "Tue, 31 Mar 2015 17:27:32 +1300") References: <87y4mehqdf.fsf@gnu.org> Message-ID: <871tk5v74j.fsf@gnu.org> On 2015-03-31 at 06:27:32 +0200, Chris Wong wrote: [...] > While it would be useful to have it in the Prelude, traverse_ doesn't > fit either of the motivations above. So I think its omission is > intended here. That is not to say that it can't be proposed for inclusion... IOW, just turn the cautious "'traverse_' is not exported from Prelude [..] Is this intentional?"-question into an explicit/proper library proposal! Cheers, hvr From mail at joachim-breitner.de Tue Mar 31 10:29:26 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Mar 2015 12:29:26 +0200 Subject: RULE traverse = traverse_? In-Reply-To: <871tk5v74j.fsf@gnu.org> References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> Message-ID: <1427797766.1451.21.camel@joachim-breitner.de> Hi, has it been considered that the compiler might be instructed to replace traverse by traverse_ if the result is not used? Are the conditions where traverse can be replaced by traverse_ well-defined? Probably not in general, but maybe for individual Traversable instances? Is this expressible in rules? At a first glance, the rule "traverse == traverse_" seems to be sound where the resulting program well-typed, as if it is well-typed in both cases, this means that the result was not used. Of course, an explicit "traverse_" is still useful, but wouldn?t it nevertheless be nice to have a sufficient smart compiler? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-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 adam at bergmark.nl Tue Mar 31 10:33:24 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 31 Mar 2015 12:33:24 +0200 Subject: Hackage trustee proposal: Curating the Hackage package collection Message-ID: Dear Haskell Community, For some time Hackage has contained a user group called "Trustees", http://hackage.haskell.org/packages/trustees/ . Description: The role of trustees is to help to curate the whole package collection. Trustees have a limited ability to edit package information, for the entire package database (as opposed to package maintainers who have full control over individual packages). Trustees can edit .cabal files, edit other package metadata and upload documentation but they cannot upload new package versions." In short, making sure that packages keep building and filling the gap between unreachable maintainers and package take-overs. Up until now we have been very careful with changes since we haven't had a defined process. Spurred by SPJ and others we have been working on a proposal for how we should operate. You can find the proposal here: https://gist.github.com/bergmark/76cafefb300546e9b90e We would now like your feedback! Some specific things from the proposal that we'd like your opinion on: * Section 1: No opt-out for restricting bounds * Section 2: Opt-out rather than opt-in procedure for loosening version constraints * Section 2: Do you care whether you are notified before or after a version constraint is loosened? * Section 3: The time frame for publishing simple source changes * Section 3: What exactly should constitute a "simple source change" We also have a github repository where YOU can file issues about broken packages, you can start doing this right now! https://github.com/haskell-infra/hackage-trustees/ Please share this with as many people as possible. We are looking forward to hear your thoughts! Sincerely, Adam Bergmark -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Tue Mar 31 10:33:33 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 31 Mar 2015 12:33:33 +0200 (CEST) Subject: RULE traverse = traverse_? In-Reply-To: <1427797766.1451.21.camel@joachim-breitner.de> References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> <1427797766.1451.21.camel@joachim-breitner.de> Message-ID: On Tue, 31 Mar 2015, Joachim Breitner wrote: > At a first glance, the rule > "traverse == traverse_" > seems to be sound where the resulting program well-typed, as if it is > well-typed in both cases, this means that the result was not used. > > Of course, an explicit "traverse_" is still useful, but wouldn?t it > nevertheless be nice to have a sufficient smart compiler? If it works it will still surprise programmers if the magic does not happen for a custom function similar to 'traverse'. E.g. I had a data structure with two type parameters and thus two traverse function parameters. I think it is better to tell programmers about the general problem instead of fixing a selection of instances. From ekmett at gmail.com Tue Mar 31 10:41:27 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 06:41:27 -0400 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: We deliberately took no more symbols than we needed in 7.10 from Prelude as part of the Foldable/Traversable Proposal. There are multiple combinators in Data.Foldable and Data.Traversable that we do not export. traverse_ is one of them as, strictly speaking, traverse_ was a symbol we didn't have to take. If we had would anybody have complained any more loudly? Not sure... but it was a deliberate choice to not bring in any symbols into Prelude that weren't already there that weren't part of the definition of a class or needed to define instances that already existed. -Edward On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita wrote: > Well, I see. It'd be nice. > > That aside, the absence of traverse_ doesn't seem to be intended (even the > documentation for mapM_ says "mapM_ is just traverse_"!) > > 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : > >> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >> >> [...] >> >> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >> nice >> > to reexamine Prelude to export things we want to export. >> >> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >> alias for `mappend`), *and* to keep our options open (or at least not >> make it more difficult) in terms of possible migration-plans available >> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >> the future. >> >> > > _______________________________________________ > 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 mail at joachim-breitner.de Tue Mar 31 10:43:06 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Mar 2015 12:43:06 +0200 Subject: RULE traverse = traverse_? In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> <1427797766.1451.21.camel@joachim-breitner.de> Message-ID: <1427798586.1451.24.camel@joachim-breitner.de> Hi, Am Dienstag, den 31.03.2015, 12:33 +0200 schrieb Henning Thielemann: > If it works it will still surprise programmers if the magic does not > happen for a custom function similar to 'traverse'. E.g. I had a data > structure with two type parameters and thus two traverse function > parameters. I think it is better to tell programmers about the general > problem instead of fixing a selection of instances. True. But that is a problem with every compiler optimization. If you have a recursive function taking some Int, the compiler might be able to determine that you use it strictly and unbox it, and great things happen. It will not always figure this out, and if it does not, you have to help it (e.g. using strictness annotations). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-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 ekmett at gmail.com Tue Mar 31 11:04:38 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 07:04:38 -0400 Subject: RULE traverse = traverse_? In-Reply-To: <1427798586.1451.24.camel@joachim-breitner.de> References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> <1427797766.1451.21.camel@joachim-breitner.de> <1427798586.1451.24.camel@joachim-breitner.de> Message-ID: In general we don't currently go out of our way to export RULES that risk breakage / semantics changes when the user supplies an instance that merely doesn't satisfy the laws. The only ones that actually come to mind are the ones hiding in Control.Arrow that I don't think anybody has looked at since they were first written. We also have a few around realToFrac that have questionable semantics that are a source of constant semantic pain as well. A fairly exotic, but known, use-case for a Traversable is to exploit the fact that we can extract given the data has a known shape and put the data back in using the same shape. This sits behind a number of tricks in my 'lens' and 'ad' libraries. If you are given a Traversable `f` in as input and spit it back out as output, and you know nothing else about `f`, you can know that the `f` you took in has the same number of entries as the one you spat out. This gives a safe way to reason about zipping things that are derived from the same input, which comes up a lot in the context of 'ad', etc. This is done in one of two ways. 1.) You can linearize the structure and you recover the shape left to right. This runs into the same problem as relying on toList to characterize a Foldable. It ignores infinite cases. (For things like AD where the infinite cases breaks down, thats fine, for other use cases it isn't.) 2.) Or you make an illegal Applicative that captures the structure as it walks in a tree. We can either replay the tree on the same Traversable (2a), or we can build a heavier GADT during construction (2b). Uniplate takes the (2a) approach, lens takes (2b) in e.g. A variant on the construction of http://hackage.haskell.org/package/lens-4.8/docs/src/Control-Lens-Internal-Magma.html#Molten for instance can use the ability to 're-walk' a Traversable on the same data type and get exactly the same arrangement of structures (including fmaps) to avoid having to store the structure in a GADT. Your proposed optimization breaks at least the (2a) approach above. The key is don't get to know that `foldMap f` and `getConst . traverse (Const . f)` for a given container build the exact same tree. One might associate differently than the other, and in fact if you supplied a definition of the Foldable in terms of foldr and the Traversable in terms of traverse, this is precisely what happens, so it isn't even an academic exercise. =/ Consequently, the walk to gather all the values in the tree can't be done with traverse_, but can be done with traverse, despite the fact that we're ignoring the result inside the monad. -Edward On Tue, Mar 31, 2015 at 6:43 AM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 31.03.2015, 12:33 +0200 schrieb Henning Thielemann: > > If it works it will still surprise programmers if the magic does not > > happen for a custom function similar to 'traverse'. E.g. I had a data > > structure with two type parameters and thus two traverse function > > parameters. I think it is better to tell programmers about the general > > problem instead of fixing a selection of instances. > True. > > But that is a problem with every compiler optimization. If you have a > recursive function taking some Int, the compiler might be able to > determine that you use it strictly and unbox it, and great things > happen. It will not always figure this out, and if it does not, you have > to help it (e.g. using strictness annotations). > > Greetings, > Joachim > > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Mar 31 11:56:26 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Mar 2015 13:56:26 +0200 Subject: RULE traverse = traverse_? In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> <1427797766.1451.21.camel@joachim-breitner.de> <1427798586.1451.24.camel@joachim-breitner.de> Message-ID: <1427802986.1625.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 31.03.2015, 07:04 -0400 schrieb Edward Kmett: > Your proposed optimization breaks at least the (2a) approach above. > > The key is don't get to know that `foldMap f` and `getConst . traverse > (Const . f)` for a given container build the exact same tree. One > might associate differently than the other, and in fact if you > supplied a definition of the Foldable in terms of foldr and the > Traversable in terms of traverse, this is precisely what happens, so > it isn't even an academic exercise. =/ This argues against a generic "traverse = traverse_" rule. But how about per-instances rules, for instances where we know that they build the applicative result in the same way? Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-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 oleg.grenrus at iki.fi Tue Mar 31 12:43:10 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 31 Mar 2015 15:43:10 +0300 Subject: [Haskell-cafe] Hackage trustee proposal: Curating the Hackage package collection In-Reply-To: References: Message-ID: <180C5F5C-16ED-43D2-9CEA-19F2FD650A5F@iki.fi> Some ideas about: What exactly should constitute a "simple source change? - Adding an extension (e.g. FlexibleContexts) to make code compile - Adding an Applicative for Monad (or similar obvious ?intristic? instance addition, e.g Semigroup for Monoids, if Semi-MP is in) - Editing import list (hiding clashing symbols, qualifying) > On 31 Mar 2015, at 13:33, Adam Bergmark wrote: > > Dear Haskell Community, > > For some time Hackage has contained a user group called "Trustees", > http://hackage.haskell.org/packages/trustees/ . > > > Description: The role of trustees is to help to curate the whole > package collection. Trustees have a limited ability to edit package > information, for the entire package database (as opposed to package > maintainers who have full control over individual packages). Trustees > can edit .cabal files, edit other package metadata and upload > documentation but they cannot upload new package versions." > > In short, making sure that packages keep building and filling the gap > between unreachable maintainers and package take-overs. > > Up until now we have been very careful with changes since we haven't > had a defined process. Spurred by SPJ and others we have been working > on a proposal for how we should operate. > > You can find the proposal here: > https://gist.github.com/bergmark/76cafefb300546e9b90e > > > We would now like your feedback! > > Some specific things from the proposal that we'd like your opinion on: > > * Section 1: No opt-out for restricting bounds > * Section 2: Opt-out rather than opt-in procedure for loosening version constraints > * Section 2: Do you care whether you are notified before or after a version constraint is loosened? > * Section 3: The time frame for publishing simple source changes > * Section 3: What exactly should constitute a "simple source change" > > > We also have a github repository where YOU can file issues about > broken packages, you can start doing this right now! > https://github.com/haskell-infra/hackage-trustees/ > > > Please share this with as many people as possible. > We are looking forward to hear your thoughts! > > Sincerely, > Adam Bergmark > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- 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 fumiexcel at gmail.com Tue Mar 31 14:11:40 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Tue, 31 Mar 2015 23:11:40 +0900 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: I understand the ground. It seems reasonable not to add symbols facilely. But in this case, the "too specialized" version is exported while more fundamental one is not. Although folks (including me) use mapM_ mostly today, someday we will like to have traverse_, I guess. 2015-03-31 19:41 GMT+09:00 Edward Kmett : > We deliberately took no more symbols than we needed in 7.10 from Prelude > as part of the Foldable/Traversable Proposal. There are multiple > combinators in Data.Foldable and Data.Traversable that we do not export. > traverse_ is one of them as, strictly speaking, traverse_ was a symbol we > didn't have to take. > > If we had would anybody have complained any more loudly? Not sure... but > it was a deliberate choice to not bring in any symbols into Prelude that > weren't already there that weren't part of the definition of a class or > needed to define instances that already existed. > > -Edward > > On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita > wrote: > >> Well, I see. It'd be nice. >> >> That aside, the absence of traverse_ doesn't seem to be intended (even >> the documentation for mapM_ says "mapM_ is just traverse_"!) >> >> 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : >> >>> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >>> >>> [...] >>> >>> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >>> nice >>> > to reexamine Prelude to export things we want to export. >>> >>> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >>> alias for `mappend`), *and* to keep our options open (or at least not >>> make it more difficult) in terms of possible migration-plans available >>> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >>> the future. >>> >>> >> >> _______________________________________________ >> 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 Tue Mar 31 15:27:34 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 11:27:34 -0400 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: I have no objection to having the discussion about widening the set of symbols to shave off warts like this in 7.12. -Edward On Tue, Mar 31, 2015 at 10:11 AM, Fumiaki Kinoshita wrote: > I understand the ground. It seems reasonable not to add symbols facilely. > > But in this case, the "too specialized" version is exported while more > fundamental one is not. > Although folks (including me) use mapM_ mostly today, someday we will like > to have traverse_, I guess. > > 2015-03-31 19:41 GMT+09:00 Edward Kmett : > >> We deliberately took no more symbols than we needed in 7.10 from Prelude >> as part of the Foldable/Traversable Proposal. There are multiple >> combinators in Data.Foldable and Data.Traversable that we do not export. >> traverse_ is one of them as, strictly speaking, traverse_ was a symbol we >> didn't have to take. >> >> If we had would anybody have complained any more loudly? Not sure... but >> it was a deliberate choice to not bring in any symbols into Prelude that >> weren't already there that weren't part of the definition of a class or >> needed to define instances that already existed. >> >> -Edward >> >> On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita >> wrote: >> >>> Well, I see. It'd be nice. >>> >>> That aside, the absence of traverse_ doesn't seem to be intended (even >>> the documentation for mapM_ says "mapM_ is just traverse_"!) >>> >>> 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : >>> >>>> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >>>> >>>> [...] >>>> >>>> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >>>> nice >>>> > to reexamine Prelude to export things we want to export. >>>> >>>> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >>>> alias for `mappend`), *and* to keep our options open (or at least not >>>> make it more difficult) in terms of possible migration-plans available >>>> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >>>> the future. >>>> >>>> >>> >>> _______________________________________________ >>> 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 Tue Mar 31 15:28:23 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 11:28:23 -0400 Subject: RULE traverse = traverse_? In-Reply-To: <1427802986.1625.2.camel@joachim-breitner.de> References: <87y4mehqdf.fsf@gnu.org> <871tk5v74j.fsf@gnu.org> <1427797766.1451.21.camel@joachim-breitner.de> <1427798586.1451.24.camel@joachim-breitner.de> <1427802986.1625.2.camel@joachim-breitner.de> Message-ID: On an instance by instance basis I have zero objection and it can definitely work fine. -Edward On Tue, Mar 31, 2015 at 7:56 AM, Joachim Breitner wrote: > Hi, > > > Am Dienstag, den 31.03.2015, 07:04 -0400 schrieb Edward Kmett: > > > Your proposed optimization breaks at least the (2a) approach above. > > > > The key is don't get to know that `foldMap f` and `getConst . traverse > > (Const . f)` for a given container build the exact same tree. One > > might associate differently than the other, and in fact if you > > supplied a definition of the Foldable in terms of foldr and the > > Traversable in terms of traverse, this is precisely what happens, so > > it isn't even an academic exercise. =/ > > This argues against a generic "traverse = traverse_" rule. But how about > per-instances rules, for instances where we know that they build the > applicative result in the same way? > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: