Re: aeson and dlist in HP 2013.4.0.0

On 28 November 2013 13:42, Sven Panne wrote: > Just two add my 2c: Given all these new packages which would need to > be pulled into the HP just for aeson, let's not include aeson for > 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy > discussions. As the proposer for inclusio

Re: aeson and dlist in HP 2013.4.0.0

* Christian Maeder [2013-11-28 12:27:30+0100] > Am 28.11.2013 11:40, schrieb Roman Cheplyaka: > >* Christian Maeder [2013-11-28 10:24:49+0100] > >>and attoparsec raises the question about how two different parser > >>packages should coexist in the HP > > > >I must have missed that — what is the q

Re: aeson and dlist in HP 2013.4.0.0

On Wed, Nov 27, 2013 at 9:28 PM, Mark Lentczner wrote: > Okay - to put a concrete proposal on this: > > 1) Include dlist-0.6, which would have the additions that Sean L. has > proposed > [...] > ​*Sean* - do you have a time frame for such changes? > [...] dlist-0.6 is ready for imminent release.

Re: aeson and dlist in HP 2013.4.0.0

Just two add my 2c: Given all these new packages which would need to be pulled into the HP just for aeson, let's not include aeson for 2013.4.0.0 and release 2013.4.0.0 soon without the need for lengthy discussions. One of the main points of the HP is stability, and doing things in a useless rush n

Re: aeson and dlist in HP 2013.4.0.0

* Christian Maeder [2013-11-28 10:24:49+0100] > and attoparsec raises the question about how two different parser > packages should coexist in the HP I must have missed that — what is the question, exactly? Roman signature.asc Description: Digital signature

Re: aeson and dlist in HP 2013.4.0.0

agreed, I think that would be a sensible choice. The key point being, every representable number should have a unique representation. On Wed, Nov 27, 2013 at 5:13 PM, Henning Thielemann < lemm...@henning-thielemann.de> wrote: > > On Wed, 27 Nov 2013, Carter Schonwald wrote: > > I'm looking at

Re: aeson and dlist in HP 2013.4.0.0

I'm looking at the scientific package, and I thought to myself "huh, it doesn't seem to normalize the numbers to scientific notation" it has the right semantics for how printing and operations *mean*, but it doesn't seem to internally keep them as "normalized" floats. heres a snippet of a ghci tr

Re: aeson and dlist in HP 2013.4.0.0

Okay - to put a concrete proposal on this: 1) Include dlist-0.6, which would have the additions that Sean L. has proposed 2) Include scientific as package 3) Include an aeson that is updated to use the above two packages (and won't use blaze-builder) ​*Sean* - do you have a time frame for such ch

Re: aeson and dlist in HP 2013.4.0.0

On Tue, Nov 26, 2013 at 4:46 AM, Gregory Collins wrote: > Is there a way to include packages as second-class in the platform? > We quasi-did that with primitives. But as I recall, the discussion at the time acknowledged the ineffectiveness of the approach: The point of the platform is that if you

Re: aeson and dlist in HP 2013.4.0.0

Is there a way to include packages as second-class in the platform? I.e. "this package isn't 'blessed' but for now it's required by a package we really do want." Then we could work later to either bring the dependencies into the platform or rework the platform packages to exclude the non-platform d

Re: aeson and dlist in HP 2013.4.0.0

My view of the conversation so far: 1) Aeson option 3 or 4 is desirable - we all want aeson, we don't want blaze-builder 2) dlist has generated a fair bit of discussion, but no clear agreement. 3) no one has weighed in on scientific We need to come to rough consensus on these issues soon if we ar

Re: aeson and dlist in HP 2013.4.0.0

Hi John, On Tue, Nov 19, 2013 at 3:32 AM, John Lato wrote: > Since I've raised this issue before as well, I decided to write some tests. > > At this time, I've written/run criterion tests, and I have some hand-wavey > theoretical arguments. The theoretical stuff came first (presented below) > an

Re: aeson and dlist in HP 2013.4.0.0

Hi Sean, Since I've raised this issue before as well, I decided to write some tests. At this time, I've written/run criterion tests, and I have some hand-wavey theoretical arguments. The theoretical stuff came first (presented below) and isn't influenced by the test results, which I haven't atte

Re: aeson and dlist in HP 2013.4.0.0

On Mon, Nov 18, 2013 at 6:21 PM, Niklas Hambüchen wrote: > On 18/11/13 15:37, Sean Leather wrote: > > Examples > > include debugging (yours), implementing functions not included in the > > library (e.g. this comes up sometimes with Data.Map/Data.Set), and > > optimization. > > ... > > > In the cas

Re: aeson and dlist in HP 2013.4.0.0

On Mon, Nov 18, 2013 at 5:40 PM, Peter Simons wrote: > ...but I never had any trouble because > a library exposed a type that I didn't need access to. > I've definitely had the experience of pattern matching on somebody's constructor and then having my code break when a new record field was adde

Re: aeson and dlist in HP 2013.4.0.0

Hi Ivan, On Mon, Nov 18, 2013 at 12:06 PM, Ivan Lazar Miljenovic wrote: > On 18 November 2013 19:04, Sean Leather wrote: > > * Deprecate `DL`, `unDL` and add `apply` > > The only possible issue I can think of with this from my own > experience in dealing with my own code with abstract data types

Re: aeson and dlist in HP 2013.4.0.0

Hi Joachim, I did not want to derail the conversation about the pros and cons of dlist, so I started a separate thread about it on the haskell-platform list [1], but perhaps I should have included the libraries list [2]. Since a few people have mentioned concerns about dlist/list conversion, I wil

Re: aeson and dlist in HP 2013.4.0.0

On Sun, Nov 17, 2013 at 10:20 PM, Mark Lentczner wrote: > Thoughts? I'm fine with any option regarding dlist. Just to update people on my planned changes for v0.6, here is the ChangeLog : * Maintenance and development taken over by Sean Le