- Libraries - Haskell.org

Proposal: Explicitly require "Data.Bits.bit (-1) == 0" property
by Herbert Valerio Riedel 08 Mar '14

08 Mar '14

Hello *, Right now, there seems to be no "defined" way to create a zero 'Bits'-value (w/o requiring also a 'Num' instance), that has all bits cleared without involving at least two operations from the 'Bits' class (e.g. `clearBit (bit 0) 0` or `let x = bit 0 in xor x x`). OTOH, introducing a new method 'class Bits a where bitZero :: a' seems overkill to me. However, "bit (-1)"[1] seems to result in just such a zero-value for all 'Bits' instances from base, so I'd hereby propose to simply document this as an expected property of 'bit', as well as the recommended way to introduce a zero-value (for when 'Num' is not available). Discussion period: 2 weeks [1]: ...or more generally 'bit n == 0' for n<0, as it's usually implemented as 'bit n = 1 shift n'

36 147

ANN: time-1.4.2
by Ashley Yakeley 03 Mar '14

03 Mar '14

time-1.4.2 is now available from Hackage. <http://hackage.haskell.org/package/time> This update is one contributed improvement, Safe Haskell annotation, from Omari Norman. Thanks! -- Ashley Yakeley

1 0

[PATCH 0/3] Implement nand/nor/nany/nall in Data.List
by Alexander Berntsen 27 Feb '14

27 Feb '14

Hi. I'm a complete GHC newbie (and, really, a Haskell newbie still as well). To dive in and learn, I hacked together this. I did it primarily to familiarise myself with GHC workflow, formalities and procedures. Things like style conventions, using Trac, learning how to build GHC, how the files are structured and so on. However, my primary intention of learning does not mean that I don't find these patches valuable. I'm sick of typing (not . and), and even more sick of reading it. I find nand much more intuitive to read. Herbert told me to send these here since they affect base. I can imagine people are vary of putting stuff in base, and certainly prelude. But if I seem ignorant and ahistorical, that's because I *am*. So please, if there is something wrong with my patches, don't hesitate to educate me. Learning the ways of GHC hacking is after all my long-term goal. :-) Alexander Berntsen (3): Implement nand, nor, nany and nall in Data.List Inline nand, nor, nany and nall Put nand, nor, nany and nall in Prelude Data/List.hs | 4 ++++ GHC/List.lhs | 38 ++++++++++++++++++++++++++++++++++++-- Prelude.hs | 2 +- changelog.md | 3 +++ 4 files changed, 44 insertions(+), 3 deletions(-) -- 1.8.3.2

10 15

Changes to time for Safe Haskell
by Omari Norman 25 Feb '14

25 Feb '14

It would be great to make some minor changes to time so that the Data.Time packages are Safe or Trustworthy for Safe Haskell. Currently I have a raft of packages that are Unsafe solely due to Data.Time being unsafe. The necessary changes are minor, and I changed nothing in the functions themselves. One module just needs to import Foreign.Safe rather than Foreign. Another is Unsafe due to use of rewrite rules; I simply marked those modules Trustworthy. Safe Haskell will be much more useful if modules that sit at the bottom of tall stacks, such as Data.Time, are Safe. Thanks, Omari

1 0

Merge either into transformers
by Roman Cheplyaka 25 Feb '14

25 Feb '14

Hi Ross, I proposed to merge either into transformers more than a year ago[1], and everyone seemed to agree. Could you please do it? [1]: http://www.haskell.org/pipermail/libraries/2012-December/019027.html Thanks, Roman

3 2

qualification of Data.Map (Was: [Mid-discussion Summary] Proposal: add new Data.Bits.Bits(bitZero) method)
by Henning Thielemann 24 Feb '14

24 Feb '14

Am 24.02.2014 22:37, schrieb Casey McCann: > The need for qualification with Data.Map (and the modules it would > clash with) is a clear wart due to lacking appropriate type classes > for collections. You probably shouldn't use that to support your > point. That's an interesting point. However, I don't believe that there is an elegant solution to e.g. unify Map.insert and Set.insert using an advanced type class. I often see people trying to resolve name conflicts by type classes, often indicated by FlexibleInstances. I think this in turn is abuse. It is certainly ok to use (<>) for different types via the Monoid class, but already this one is difficult, because for Maps there are different sensible implementations. That is, we won't get rid from names with module dependend types, we cannot and should not resolve every conflict using type classes. There are many cases where the module system is the better tool than advanced type hacks.

1 0

Re: RFC: include a cabal-install executable in future GHC releases
by Austin Seipp 23 Feb '14

23 Feb '14

Hello, My input is this: I think a lot of confusion stems from some documentation that just needs to be cleared up. I think that just cleaning up the pages so that: * http://www.haskell.org/cabal has binaries for Tier 1 platforms: OS X, Windows, FreeBSD i386/amd64, Linux i386/amd64. IMO, there should be a clear 'Download pre-built binaries' on the immediate front page that cannot be missed. * http://www.haskell.org/ghc/download still points to the platform for most users (i.e. the platform is more long-term stable/supported,) but also mentions cabal install binaries. They can be linked to directly from the subsection for each platform: "Download GHC 7.8.1 Mac OS X x86-64 - also download <latest cabal-install OS X build> from here" I personally think this would go a significant way to making it easier for people to bootstrap environments. (IMO, both the GHC and Cabal homepage could both do with a visual makeover as well, to make this all the more apparent and easily accessible.) As for cabal install binaries: I can easily provide dedicated hardware (thanks to Rackspace) for Windows, FreeBSD or Linux build machines. I also have a dedicated OS X machine in Oxford (thanks to Duncan) that can be used to build binaries for OS X as well. So I can absolutely provide resources for Cabal developers to build them if they'd like. At least for T1 platforms. As for shipping with GHC itself: this is technically possible, but slightly annoying to implement, and it also makes the build processes for a release slightly more annoying (which is mostly my problem.) But it is all doable. However, keep in mind I *do not* maintain the binary distributions for everything, nor do Cabal devs have access to all hardware - so all people making upstream releases for their platforms (i.e. Solaris, PowerPC, ARM/Linux, etc) must also package cabal themselves. But perhaps that's not a huge deal. I guess my vote on this is ultimately neutral. I think it can be fixed by simply making the downloads more clear. Alternatively we can package cabal-install. I'll leave the decision up to users at large and their votes. On Sun, Jan 26, 2014 at 7:08 AM, Daniil Frumin <difrumin(a)gmail.com> wrote: > cabal-install doesn't even have to be distributed in one tar.gz with > GHC, just merely mentioning cabal-install binaries on > http://www.haskell.org/ghc/download will surely help (assuming we get > to actually have the cabal-install binaries :) > > On Sat, Jan 25, 2014 at 10:48 PM, Gábor Lehel <glaebhoerl(a)gmail.com> wrote: >> +1 to this proposal. The benefits are obvious and practical: when installing >> a new GHC, it will save users the tedium of having to figure out how to >> build a cabal-install and then do so before they can install the packages >> they actually want. The drawbacks are indefinite and amorphous: the download >> is a little bit larger. So what? It further blurs the line between GHC and >> the Platform. Who does this harm? People who already have a cabal-install >> will now have a second one. What discomfort will this cause them? >> >> >> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >> <carter.schonwald(a)gmail.com> wrote: >>> >>> Hey everyone, >>> >>> I'd like to propose that GHC releases 7.8.1 onwards include a >>> cabal-install (aka cabal) executable, but not include the library deps of >>> cabal-install that aren't already distributed with ghc.(unless ghc should >>> have those deps baked in, which theres very very good reasons not to do.). >>> >>> currently if someone wants just a basic haskell install of the freshest >>> ghc they have to install a ghc bindist, then do a boostrap build of >>> cabal-install by hand (if they want to actually get anything done :) ). >>> >>> This is not a human friendly situation for folks who are new to haskell >>> tooling, but want to try out haskell dev on a server style vm or the like! >>> >>> point being: It'd be great for haskell usability (and egads amounts of >>> config time, even by seasoned users) the ghc bindists / installers included >>> a cabal-install binary >>> >>> thoughts? >>> -Carter >>> >>> >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > > -- > Sincerely yours, > -- Daniil > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

[base] Fix off-by-one error in writeBlocks
by Niklas Haas 22 Feb '14

22 Feb '14

I've noticed an off-by-one issue in writeBlocks which writes a character fewer than expected per block buffer in block buffering mode, when not using CRLF mode (+ adding a newline). I've implemented a patch which fixes this particular issue, but I haven't eyeballed the Core or benchmarked it thoroughly to make sure it's not a big performance regression. The only concern I have, apart from performance, is that due to the way the loop works we technically inspect the next cons cell *before* actually flushing the buffer, so it's too strict by exactly one character. I didn't know how to solve this without inverting the entire loop though, and I'm very wary of the performance impact that would have. I would appreciate feedback and comments. Is this issue worth pushing the change in the first place? Discussion period: 2 weeks

1 0

Thank you for the donations to Haskell.org!
by Jason Dagit 18 Feb '14

18 Feb '14

On behalf of Haskell.org, we would like to thank all the generous donors we had in 2013! Just in the last week of the year, we received about half of the total donations for the year. Nearly $900! That brings the total donations for the year to $1976! Thank you very much! We are very grateful for all the donations we receive, financial and otherwise. As examples, GlobalSign graciously provides us with a free SSL certificate for use on hackage and each year community members collectively provide countless hours of time and energy towards making the Haskell community vibrant, positive, and relevant. At the moment our primary expenses are hosting for haskell.org and hackage. The donations we have received will help ensure that we continue to have adequate hosting for the ever growing hackage! Thank you and let's continue our momentum into 2014! Sincerely, The Haskell.org Committee

1 0

Adding (??) into Data.Functor
by Dimitri Sabadie 17 Feb '14

17 Feb '14

Hi all, I often come up using this snippet: map ($ a) l with l :: [a -> b] In Control.Lens, there's a nice combinator for that, (??) : l ?? a I think it'd be great to include that in Data.Functor, because it's a very common use case.

6 11