September 2013 - Libraries

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

Re: throwTo semantics
by Bertram Felgenhauer 10 Sep '13

10 Sep '13

Simon Marlow wrote: > On 28/07/13 14:36, Roman Cheplyaka wrote: > >The documentation for throwTo says: > > > > throwTo does not return until the exception has been raised in the > > target thread. The calling thread can thus be certain that the target > > thread has received the exception. This is a useful property to know > > when dealing with race conditions: eg. if there are two threads that > > can kill each other, it is guaranteed that only one of the threads > > will get to kill the other. > > > >I don't see how the last sentense follows. I understood it so that the > >implication > > > > throwTo has returned => exception has been delivered > > > >is true, but not the reverse. If my understanding is correct, then both > >exceptions could be delivered without any of throwTos returning. > > Perhaps this needs to be clarified. How about the attached patch? Best regards, Bertram

1 0

Proposal: Improving the IsString String instance
by Edward Kmett 09 Sep '13

09 Sep '13

I've been chewing on this one for a long time, and finally decided to post it after being bitten by it *again*. Right now we have a very fragile instance in base for instance IsString String where fromString = id This is fragile because once you turn on OverloadedStrings length "hello" won't work any more, because all it knows is that it has a [a] such that it needs an IsString [a] instance, but it can't use defaulting to select the [Char] instance we've defined, and so you have to burden it with a type annotation. >>> :set -XOverloadedStrings >>> length "hello" <interactive>:3:8: No instance for (Data.String.IsString [a0]) arising from the literal `"hello"' The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there is a potential instance available: instance Data.String.IsString [Char] -- Defined in `Data.String' Possible fix: add an instance declaration for (Data.String.IsString [a0]) In the first argument of `length', namely `"hello"' In the expression: length "hello" In an equation for `it': it = length "hello" I would like to replace this instance with instance a ~ Char => IsString [a] where fromString = id This will make OverloadedStrings work much better with the list-specific combinators, reducing the number of type annotations required by users who hack on, say, web-apps in Haskell where both OverloadedStrings is a common extension and, frankly, the users are often the least equipped to deal with and understand the issue. The cost of this instance is that someone else can't come along and make an instance of IsString for another 'character-like' type and get the String-like behavior with magic list interoperability without some kind of wrapper. However, I've yet to see any such instances, and I'd likely look down my nose at such an instance in the first place. ;) The current pain is real and the space of instances affected seems both largely theoretical and a bad idea to begin with. The instance is already guarded from use by NHC by an #ifdef, which limits objections on portability grounds. Discussion Period: 2 Weeks

24 49

ANN: unix-bytestring 0.3.7
by wren ng thornton 08 Sep '13

08 Sep '13

-------------------------------------------- -- unix-bytestring 0.3.7 -------------------------------------------- The unix-bytestring package offers a full selection of Unix/Posix-specific functions for reading and writing ByteStrings to Fds. -------------------------------------------- -- Changes (since 0.3.4) -------------------------------------------- Most of the changes are for portability with newer versions of GHC, though the 0.3.7 release corrects a major bug on certain systems. I'd like to thank John Lato, Kazu Yamamoto, and Gergely Risko for their help with these patches. 0.3.5 (2011-06-29): - System.Posix.IO.ByteString: added fdSeek, tryFdSeek. - Foreign.C.Error.Safe: added. 0.3.5.3 (2012-02-21): - Foreign.C.Error.Safe: changed (Num a) to (Eq a, Num a) for GHC 7.4 0.3.5.4 (2012-08-23): - System.Posix.IO.ByteString: adjusted some imports for GHC 7.6 - Removed the custom Setup.hs, for compatibility with GHC 7.6 0.3.6 (2013-05-29): - System.Posix.Types.Iovec: adjusted unsafeForeignPtrToPtr for GHC 7.8 0.3.7 (2013-08-08): - System.Posix.IO.ByteString: corrected a bug in fdSeek and tryFdSeek where the return value was always 0 on largefile i686 systems due to the underlying C function being (undocumentedly) implemented as a macrocall. This had been fixed in unix-2.6.0.1, and I've just backported their fix, cf: * <https://github.com/ghc/packages-base/blob/master/System/Posix/Internals.hs#…> * <https://github.com/ghc/packages-unix/blob/master/System/Posix/IO/Common.hsc…> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unix-bytestring Darcs: http://community.haskell.org/~wren/unix-bytestring Haddock (Darcs version): http://community.haskell.org/~wren/unix-bytestring/dist/doc/html/unix-bytes… -- Live well, ~wren

1 0

Proposal: undeprecate Data.ByteString.Lazy.Builder
by Dag Odenhall 04 Sep '13

04 Sep '13

…and deprecate Data.ByteString.Builder. Why? - It would be more consistent with Data.Text.Lazy.Builder - It does in fact build lazy bytestrings - But most importantly, Data.ByteString.Builder is not available in the version shipped with current GHC or Haskell Platform! I fear this last point will force a lot of ugly #ifdefs for code that wants to support a range of versions in the future. A common goal is to support the last three major GHC versions. This would mean we can't start to use Data.ByteString.Builder unconditionally before GHC 7.12, and neither can we use Data.ByteString.Lazy.Builder unconditionally if it is dropped before that or DEPRECATED warnings are added and we want to build without warnings. On the other hand, if you want to support three GHC versions back it still means you can't use Builder without blaze-builder before 7.10. Perhaps we should just pretend that Builder never made it into 7.6, because 7.8 will be the first version with Data.ByteString.Builder? Discuss!

1 0

Documenting which element maximumBy selects
by Niklas Hambüchen 03 Sep '13

03 Sep '13

maximumBy will select the *last* maximal element. I propose that we document that.

2 1

status of network package
by harry 02 Sep '13

02 Sep '13

Does anyone know the status of the network package? It has 34 open issues on Github, 9 open pull requests, and no commits or merges for half a year. -- View this message in context: http://haskell.1045720.n5.nabble.com/status-of-network-package-tp5735386.ht… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

3 4