- Libraries - Haskell.org

Call for consensus: addition of split package to platform
by Brent Yorgey 24 Sep '12

24 Sep '12

Hi everyone, Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki: http://trac.haskell.org/haskell-platform/wiki/Proposals/split Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not. I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are: 1) just use a generic version of 'build' (simplest option) 2) use only GHC's version of build (slightly faster) 3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome) -Brent

2 2

HP 2012.4.0.0 -- No more proposals, Time to nail things down
by Mark Lentczner 21 Sep '12

21 Sep '12

As per the schedule, the call for proposals has ended. While the HP process allows proposals at anytime, I've set a cut off for those that will be included in the next release, HP 2012.4.0.0. The proposals before us, and my rough reading on state of the consensus of each, are: - *async* - general agreement to includ - *split* - general agreement to includ - *time-extras* - general agreement to exclude, as the instances it provided are now provided by *time* itself. - *vector* - rough agreement that the functionality should be in the platform with two sticking points: - remove the .Safe modules, I believe Roman has prepared a new version with this change - reconsider the name of the dependent *primitive* package, which would also have to be included. There is one more issue: *OpenGL* and *GLUT* in the platform are very down-rev, because later versions were split into a number of packages which didn't meet with agreement for inclusion in the platform. There has been discussion on what to do about this situation, but no proposals were made. We may run into a build issue, which might force a decision later in this release cycle. Now is the time for any further discussion of these matters. I will need to make go/no-go decisions for the 2012.4.0.0 release in little over a week: - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list - *October 15th, 2012* - First candidates — Mark *keep them doggies movin'* Lentczner**

1 0

MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption
by Herbert Valerio Riedel 19 Sep '12

19 Sep '12

Hello, When I noticed the recently released HTTP-4000.2.5[1] package used a CABAL-flag based approach[2] for what I expected the use of a macro MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't totally sure whether there was any down-side with the MIN_VERSION_-approach. So my question is: Is it always desirable to prefer the MIN_VERSION_ approach over a CABAL-flag approach for supporting multiple API versions of a dependent package (if both ways are possible)? And if not, when should I prefer which approach? [1]: http://hackage.haskell.org/package/HTTP-4000.2.5 [2]: https://github.com/haskell/HTTP/commit/7a266219284ff33d66fa5e3f67f406c2616f… [3]: https://github.com/haskell/HTTP/pull/30 cheers, hvr --

5 6

Re: GHC 7.6.1 / System.IO.Error.try
by John Lato 19 Sep '12

19 Sep '12

> From: Brandon Allbery <allbery.b(a)gmail.com> > > On Mon, Sep 17, 2012 at 2:41 PM, Oren Ben-Kiki <haskell-oren(a)ben-kiki.org>wrote: > >> It seems that System.IO.Error no longer exports "try" and that breaks a >> lot of packages I am using. I am trying to move my code to GHC 7.6.1, and >> this seems to be a common source of problems (there are other issues, >> alas...). Is there an ETA to when libraries would be GHC-7.6.1-compatible? >> > > Most of that stuff should be in Control.Exception, fwiw. System.IO.Error's try (and catch) is not the same as that of Control.Exception, because it only catches IOError's. catch is slightly more involved to change because its type is specified as catching only IOError, whereas Control.Exception.catch nearly always needs a manual annotation of the exception type. Replacing System.IO.Error.try with System.IO.Error.tryIOError should work, and is compatible with ghc's back to 7.2. John L

2 1

Default configuration of Cabal
by Oren Ben-Kiki 18 Sep '12

18 Sep '12

Why isn't the default configuration: doc-index-file: $datadir/doc/$compiler/index.html install-dirs global docdir: $datadir/doc/$compiler/$pkgid bindir: $datadir/bin-$compiler Currentlly, trying to use multiple compilers with the default settings causes conflicts in both the documentation and binary directories. If this would break too much stuff, how about covering the "best practice" for multiple compilers configuration in the cabal documentation?

1 0

GHC 7.6.1 / System.IO.Error.try
by Oren Ben-Kiki 17 Sep '12

17 Sep '12

It seems that System.IO.Error no longer exports "try" and that breaks a lot of packages I am using. I am trying to move my code to GHC 7.6.1, and this seems to be a common source of problems (there are other issues, alas...). Is there an ETA to when libraries would be GHC-7.6.1-compatible? Thanks, Oren Ben-Kiki

2 2

Relaxin the PVP with regards to adding instances
by Johan Tibell 15 Sep '12

15 Sep '12

Hi all, The PVP says: "A.B is known as the major version number, and C the minor version number. When a package is updated, the following rules govern how the version number must change relative to the previous version: 1. If any entity was removed, or the types of any entities or the definitions of datatypes or classes were changed, or instances were added or removed, then the new A.B must be greater than the previous A.B. Note that modifying imports or depending on a newer version of another package may cause extra instances to be exported and thus force a major version change." The part about adding instances and the one about modifying imports makes it hard to follow the PVP. Bumping the major version number is a quite disruptive change for your users if they use upper bounds on their dependencies. Minor version bumps are not nearly as disruptive as you can you can depend on x.y.* as long as you only use qualified imports and/or explicit import lists. Assuming no one uses orphan instances, adding instances is always safe because you can only add instances for types from packages you depend on, which means that they can't be depending on your package in turn and have defined a non-orphan instance for a type or class defined in your package. I suggest that the rule be changed to not require a major version bump if instances are added. P.S. I believe the same reasoning can be applied to the import part of the rule above. -- Johan

13 26

System.Process.ByteString.readProcess, readProcessWithExitCode
by David Fox 15 Sep '12

15 Sep '12

Attached is a module containing ByteString analogs of two functions from System.Process: readProcess and readProcessWithExitCode. I use these a lot and would love to see them incorporated into a standard library, though I'm not sure which one.

4 10

Adding scanl'
by Niklas Hambüchen 14 Sep '12

14 Sep '12

I would like to propose adding a the functions scanl' and scanl1' to Data.List. The presence and regular use of foldl' and foldl1' suggests that corresponding scan functions should be available. > scanl' :: (a -> b -> a) -> a -> [b] -> [a] > scanl' f q ls = q `seq` (q : (case ls of > [] -> [] > x:xs -> scanl' f (f q x) xs)) What do you think? Niklas

5 10

HTTP and character encodings
by Ganesh Sittampalam 13 Sep '12

13 Sep '12

Hi, tl;dr: I'd like to remove the String instances from the HTTP package. The HTTP library is overloaded on the type for request and response bodies; there are instances for String and both strict and lazy Bytestrings. Unfortunately, the String instance is rather broken. A String ought to represent Unicode data, but the HTTP wire format is bytes, and HTTP makes no attempt to handle encoding. In particular uploaded data (e.g. in POSTs) gets silently truncated and downloaded data is improperly embedded as one byte per character no matter what encoding the server advertises in the Content-Type header. (https://github.com/haskell/HTTP/issues/28) I've spent a while investigating the option of making HTTP encode and decode Strings appropriately, but my tentative conclusion is that it's too hard: - on upload we'd have to pick an encoding by default - probably UTF-8 - and also add it to the Content-Type header which may involve messing with any header supplied by the user. If the user supplied a different encoding in Content-Type then we probably would need to notice and respect that. - on upload Content-Length may also need to be managed somehow. - on download we'd need to be able to handle at least common encodings that the server might send, but on Windows even common encodings like iso-8859-* don't exist and there aren't always appropriate substitutes. - on download we'd also really want to parse HTML/XML documents looking for in-document specifications of the encoding in META tags and XML declarations (see http://www.w3.org/QA/2008/03/html-charset.html) - we'd need to also parse Content-Type to detect when the data is supposed to be binary, and then check that it is actually 8-bit clean on upload. If the user doesn't supply Content-Type at all, then what? I think the right way to do this would be to have proper high-level and low-level APIs where only the high-level API supports strings but also does a lot more active management of standard HTTP headers like content-type/content-length. But HTTP as it stands is a long way from doing that and a short-term fix is needed. So I'm reluctantly drawn to the conclusion that the only reasonable thing to do is to remove the String instances from HTTP completely for now. I imagine this could be quite disruptive, but on the other hand people using the String instance are getting silently broken behaviour and a couple of people have been bitten by this recently. Any thoughts? Cheers, Ganesh

11 24