- Libraries - Haskell.org

add INLINEABLE to maybe, either, bool
by Carter Schonwald 26 Sep '13

26 Sep '13

Its come to my attention that maybe, either, and its new sibling bool, all lack the INLINEABLE attribute, or its more aggressive sibling INLINE this seems like one of those operations where inlining in client use sites is a good option to have, and currently not possible! theres probably other stuff that would benefit from an INLINEABLE pragma in base, but this is an obvious, simple, "easy win" that I noticed when Oliver's patch got merged into base. Thoughts? Time scale: sometime this week? (ghc 7.8 merge window is landing!) cheers

12 21

Re: I've moved the primitive package to github
by Roman Leshchinskiy 26 Sep '13

26 Sep '13

Can't post to ghc-devs from the other address so here it is again... I'm awfully sorry to have gone silent but I just can't find the time for hacking any longer. If someone wants to take over primitive and vector please feel free to do so, I'd be very grateful. Roman On 24/09/13 14:30, Bryan O'Sullivan wrote: > Roman seems to have gone silent, and primitive being broken with GHC > HEAD means that there's a ton of packages we can't build right now. > > Accordingly, I've imported the old darcs repo into git and published it > on github. > > https://github.com/haskell/primitive > > Austin, please plan to fix the GHC build to get its copy of primitive > from here, once we have it working with HEAD.

2 1

findExecutable patch and additions
by Muhaimin Ahsan 22 Sep '13

22 Sep '13

http://ghc.haskell.org/trac/ghc/ticket/2184#comment:13 I've provided a new implementation of findExecutable which actually checks for the executable bit on non-windows platforms. In addition to that, there are also new functions implemented (see the #2184 comment 13). --- Muhaimin Ahsan

1 0

Re: Proposal: Add hasBitSize to Data.Bits.Bits
by John Lato 19 Sep '13

19 Sep '13

> From: Edward Kmett <ekmett(a)gmail.com> > > On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <igloo(a)earth.li> wrote: > >> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote: >> > There is currently no way to know whether or not calling >> > Data.Bits.bitSizewill crash your program. >> > >> > I propose extending the Bits class to include: >> > >> > hasBitSize :: Bits b => b -> Bool >> > >> > such that it returns False for Integer and True for the other instances > > Would it be better to move bitSize into a separate class? > > > I don't think so. Ultimately, you should be able to know for every numeric > type if it has a fixed or variable number of bits. In a perfect world 'd > rather just have bitSize return a Maybe that way we don't have to truck > with partial functions in the API. > > However, the case for just adding hasBitSize is that it avoids breaking > existing code. Given that existing code using bitSize can already cause a crash when used with Integer or other infinite types, wouldn't it be better to break existing code so authors can fix (or at least examine) their use of bitSize? I'm in favor of changing the type of bitSize, although since none of my code uses that function it's an easy position for me to take. John L.

13 40

Proposal: Replace Text.Printf with extensible, complete version
by Bart Massey 18 Sep '13

18 Sep '13

Greetings. This proposal is an extension of previous discussion on the libraries list about replacing Text.Printf with my updated version that provides extensibility of printf to user datatypes and implements much more of the C printf spec, while maintaining backward-compatibility with existing users of printf. There is a separable proposal to move Text.Printf from base into its own package. I support that proposal, but believe that we can take them in either order, and this is the part I know how to do :-). Attached please find a patch that implements the proposal. Note that it also makes slight, backward-compatible modification to Numeric and GHC.Float to avoid a whole bunch of pointless code duplication. The printf patch is kind of ugly because so much of Text/Printf.hs has been replaced. Let me know if it would be better to just provide the whole source. The patch applies and builds against my current top-of-tree GHC. While I would welcome shortening the discussion given how much has already been discussed, Monday 30 September is two weeks from today, so I will treat that as the discussion deadline unless I hear otherwise. Thanks much for the potential opportunity to contribute to the Haskell libraries! Bart Massey bart(a)cs.pdx.edu

2 8

Proposal: Add bool to Data.Bool
by Oliver Charles 15 Sep '13

15 Sep '13

Hello, I would like to propose that the following is added to Data.Bool in base: bool :: a -> a -> Bool -> a bool f _ False = f bool _ t True = t (Aka, bool f t b = if b then t else f) The purpose of this is hopefully evident from its definition. I find myself reaching for this in cases similar to where I would use 'maybe' - often when I'm working with 'fmap' and don't want to start introducing names for the function I am using to map over some functor. I suggested this in #haskell and other people also seem frustrated this doesn't exist, and would like to see it happen - hopefully they will voice their support as a reply here. A quick search on FPComplete's Hoogle [1] shows five equivalent functions on the first page - and I'm sure there are more on subsequent pages. Thoughts? - ocharles --- [1]: https://www.fpcomplete.com/hoogle?q=Bool+-%3E+a+-%3E+a+-%3E+a&env=ghc-7.4.2…

17 29

Proposal: infixr 9 `Compose`
by Bas van Dijk 13 Sep '13

13 Sep '13

I was just bitten by the fact that the type constructor Compose from Data.Functor.Compose associates to the left instead of to the right like function composition. I would like to propose adding the following to Data.Functor.Compose: infixr 9 `Compose` -- analogous to the fixity of (.) This will likely break existing code which uses Compose infix like in the following type: a `Compose` b `Compose` c Discussion deadline: 13 September 2013. Bas

2 5

Data instance for Data.Version
by David Lazar 13 Sep '13

13 Sep '13

Hi, Can we derive Data for Data.Version.Version? It would benefit Cabal. Thanks, David

4 4

mapM_ for bytestring
by Artyom Kazak 12 Sep '13

12 Sep '13

Would this be an appropriate place to propose adding mapM_ (and then possibly mapM) to bytestring library? Was it suggested before? If yes, why was it rejected?

12 30

Text.Printf replacement?
by Bart Massey 12 Sep '13

12 Sep '13

Greetings all! It's been many years since I have been subscribed to this list, and now I come back with a big ask. :-) Here goes... (tl;dr: I'd like to replace Text.Printf with a "better" version I've written. I could use some help to get this to happen.) If you go to http://github.com/BartMassey/extensible-printf you will find Text.Printf.Extensible, my substantially-rewritten version of Text.Printf. * The primary goal, as the name suggests, was to allow the extension of Haskell printf to user datatypes, a goal I achieved by modifying the Text.Printf source using roughly the approach suggested by Meacham and Marlow in an old email thread here. By the time I was done with everything, I'd made changes to much of the source, but the structure and a lot of the code is still recognizably there. I documented everything a bit more in the process of figuring out how it all worked. * A second goal was to extend printf to support as much of the C printf(3) format string syntax as seemed practicable: I did that, too. See the documentation for details. * A third goal was to produce something that was somewhat tested. See http://github.com/BartMassey/printf-tests for a test suite of 300+ tests, gathered from printf test suites found on the Internet, that Text.Printf.Extensible passes. (Text.Printf fails about half of them.) * A fourth goal was to be 100% backward-compatible with the existing Text.Printf. I haven't done sufficient testing to be sure, but on the face of it existing programs should just work. So here's the deal: I could just push this onto Hackage as extensible-printf and call it a day. However, then we'd still have a known-broken and not-extensible standard Text.Printf, and extensible-printf would have to be maintained forever. Better, IMHO, is to just replace the existing Text.Printf code with my rework. One issue is that I would love to have someone who is not me shepherd this work through the Library Submission process. I don't read this email list so regularly, and so I'd be bad at facilitating an active discussion. Another issue is that a patch should be done to merge the tiny changes in Text.Printf.Extensible.AltFloat back into Numeric. I'm happy to prepare such a patch, but someone will have to show me how to build base so that I can test my work. Is there any way to do it without also building GHC? I tried, and became very confused. A final issue has to do with the return type of Text.Printf.printf, which is polymorphic between String and IO a. I'm sure this seemed like a good idea at the time, but it's not so ideal today: GHC gives a warning when printf is used at IO a unless you explicitly ignore the result. (Worse still, if you mistakenly try to *use* the result, you'll likely end up with a run-time error.) The obvious choices are to somehow get printf to return String / IO () instead, something I could not figure out the type magic to accomplish, or to provide some alternate names for non-return-polymorphic functions. I'm leaning toward putFmt, hPutFmt (synonymous with hprintf) and sFmt, but I'm totally open to alternate suggestions. If we go forward, though, it seems like this is something we should fix one way or the other. If someone can figure out the type magic, we could fix it regardless. Thanks much for reading! Regardless, the code was fun to write, and I hope it will be useful to someone other than me. Bart Massey bart(a)cs.pdx.edu

14 29