October 2010 - Libraries

Remove some apparerntly dead TH functions
by Simon Peyton-Jones 22 Oct '10

22 Oct '10

This is a library propsal. There are a handful of functions in the template-haskell package, module Language.Haskell.TH.Lib, that are defined in that module, but are not used, and are not exported by the main Template Haskell interface Language.Haskell.TH. I propose to nuke them. I assume no one is using them (since they are not exported by the main interface), and I'm not keen on the API of rename. Moreover, rename becomes signficantly more compilcated with the advent of view patterns. The functions are: combine :: [([(Name, Name)], Pat)] -> ([(Name, Name)], [Pat]) -- Seems to be a helper for rename rename :: Pat -> Q ([(Name, Name)], Pat) genpat :: Pat -> Q ((Name -> ExpQ), Pat) alpha :: [(Name, Name)] -> Name -> ExpQ simpleMatch :: Pat -> Exp -> Match -- This is the most defensible; it's a "smart constructor" Deadline 2 weeks. http://hackage.haskell.org/trac/ghc/ticket/4423 Simon

7 6

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)
by Michael Snoyman 22 Oct '10

22 Oct '10

On Fri, Oct 22, 2010 at 11:36 AM, Sigbjorn Finne <sigbjorn.finne(a)gmail.com> wrote: > > > On Fri, Oct 22, 2010 at 9:35 AM, Sittampalam, Ganesh > <ganesh.sittampalam(a)credit-suisse.com> wrote: >> >> Bit Connor wrote: >> > On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke >> > <claus.reinke(a)talk21.com> wrote: >> >>> After it catches this error, the function returns (line 376): >> >>> >> >>> return (fail (show e)) >> >>> >> >>> The "fail" is running in the Either monad (The Result type = >> >>> Either). This calls the default Monad implementation of fail, which >> >>> is just a call to plain old error. This basically causes the entire >> >>> program to crash. >> >> >> >>> Actually, it appears that simpleHTTP isn't actually supposed to >> >>> throw an IOException, and it is instead supposed to return a >> >>> ConnError result. So the real fix is to fix the code to make this >> >>> happen. But >> >> >> >> Sounds like a victim of >> >> http://hackage.haskell.org/trac/ghc/ticket/4159 >> >> >> >> For mtl clients, 'fail' for 'Either' used to call 'Left'. That was >> >> changed, though the ticket does not indicate the library versions >> >> affected. >> > >> > This looks like the problem. Any idea how to get the HTTP package >> > fixed? I could try making a patch myself, but I would prefer hearing >> > from the HTTP maintainer first, who doesn't seem to be around. >> >> >> I've tried contacting him a few times about getting the base dependencies >> in HTTP bumped and an upload made, without success. This is a widely used >> package that's in the platform and that won't work with GHC 7.0 with the >> current dependencies, so it really needs to get fixed soon. >> >> libraries@, what's the right way to proceed? Can I make a Debian-style >> "non-maintainer upload" with minimal changes to fix urgent issues like >> these? > > I'd be much obliged if you could, and I do apologise for leaving all of this > just hanging. > No time available for Haskell projects these days unfortunately, Opera > engine development taking up most of my waking hours. Getting someone to > take over HTTP would be best, or maybe rewrite it altogether..it is not the > prettiest thing around :) I know it may not be appropriate as-is due to its dependency list, but http-enumerator[1] may be something to consider. It's still young, but I think the API is pretty clean, and I've heard from users that it performs favorably versus HTTP. Michael [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/http-enumerator

1 0

RE: [Haskell-cafe] Bug in HTTP (bad internal error handling)
by Sittampalam, Ganesh 22 Oct '10

22 Oct '10

Bit Connor wrote: > On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke > <claus.reinke(a)talk21.com> wrote: >>> After it catches this error, the function returns (line 376): >>> >>> return (fail (show e)) >>> >>> The "fail" is running in the Either monad (The Result type = >>> Either). This calls the default Monad implementation of fail, which >>> is just a call to plain old error. This basically causes the entire >>> program to crash. >> >>> Actually, it appears that simpleHTTP isn't actually supposed to >>> throw an IOException, and it is instead supposed to return a >>> ConnError result. So the real fix is to fix the code to make this >>> happen. But >> >> Sounds like a victim of >> http://hackage.haskell.org/trac/ghc/ticket/4159 >> >> For mtl clients, 'fail' for 'Either' used to call 'Left'. That was >> changed, though the ticket does not indicate the library versions >> affected. > > This looks like the problem. Any idea how to get the HTTP package > fixed? I could try making a patch myself, but I would prefer hearing > from the HTTP maintainer first, who doesn't seem to be around. I've tried contacting him a few times about getting the base dependencies in HTTP bumped and an upload made, without success. This is a widely used package that's in the platform and that won't work with GHC 7.0 with the current dependencies, so it really needs to get fixed soon. libraries@, what's the right way to proceed? Can I make a Debian-style "non-maintainer upload" with minimal changes to fix urgent issues like these? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

1 0

Re: Haskell Platform Proposal: add the 'text' library
by John Lato 21 Oct '10

21 Oct '10

> From: Roman Leshchinskiy <rl(a)cse.unsw.edu.au> > > On 17/10/2010, at 21:25, Bryan O'Sullivan wrote: > > > On Mon, Oct 11, 2010 at 1:12 PM, Malcolm Wallace <malcolm.wallace(a)me.com> > wrote: > > > > The breakSubstring functionality is semantically: > > breakSubstring x = break (==x) > > although there may be a more efficient implementation. > > Proposal: rename Text.break to Text.breakSubstring, and Text.breakBy to > Text.break. > > > > So far, I've been proceeding on the basis that I'd like naming to be > consistent and descriptive, and to have more commonly used functions get > shorter names than their less commonly used (but possibly more general) > cousins. For instance, breakSubstring is descriptive, and it's consistent > with bytestring, but it's much longer than break, even though breaking on a > fixed string is more common. In this case, length and frequency of use trump > the other considerations in my mind. > > FWIW, I take almost exactly the opposite approach with vector. I try to > follow the list/array interface as closely as possible even in the presence > of more frequently used but subtly different operations. My rationale is > that typing a few extra characters is vastly preferable to having to search > through the docs to find out what this particular library calls this > particular function. > I think there's a significant difference between vector and text, namely a Vector is conceptually the same as a list/1D array, while a Text is not. I think this difference is enough to warrant a break from the list API. John

14 19

Refer to 'mask' instead of 'block' in documentation of Control.Exception
by Bas van Dijk 21 Oct '10

21 Oct '10

Hello, Attached is a small documentation fix for Control.Exception that replaces references to the deprecated 'block' with the recommended 'mask' combinator. There's one line in the section 'Applying mask to an exception handler' that I'm not sure about what to do with: "If you need to unblock asynchronous exceptions again in the exception handler, just use 'unblock' as normal." Do we really need to point users to a deprecated function? Regards, Bas

2 1

Patch to fix warning for stm
by Bas van Dijk 20 Oct '10

20 Oct '10

Attached is a patch for stm that get rids of: Control/Concurrent/STM/TArray.hs:1:12: Warning: -fglasgow-exts is deprecated: Use individual extensions instead Bas

1 0

Proposal: Add throwSTM and generalize catchSTM
by Bas van Dijk 19 Oct '10

19 Oct '10

Dear all, Currently the only way to throw an exception in an STM transaction is via throw. The IO monad has the throwIO function which guarantees ordering with respect to other IO actions. It would be nice to have a similar function for the STM monad: throwSTM :: Exception e => e -> STM a I propose adding this to Control.Monad.STM. Additionally I propose to generalize: catchSTM :: STM a -> (SomeException -> STM a) -> STM a to: catchSTM :: Exception e => STM a -> (e -> STM a) -> STM a to make it consistent with the IO catch function: catch :: Exception e => IO a -> e -> IO a -> IO a and allow packages like exception-monads-fd/tf to define an instance MonadException STM. I don't have a patch because I think these changes also require modifying/extending the rts which I don't feel comfortable with doing right now. Discussion deadline: Three weeks, until Sunday 17th October (because of ICFP). Ticket: http://hackage.haskell.org/trac/ghc/ticket/4343 Regards, Bas

6 13

Text: find
by Antoine Latter 17 Oct '10

17 Oct '10

On Sun, Oct 17, 2010 at 3:25 PM, Bryan O'Sullivan <bos(a)serpentine.com> wrote: > On Mon, Oct 11, 2010 at 1:12 PM, Malcolm Wallace <malcolm.wallace(a)me.com> > wrote: >> >> find find find (Text -> Bool) -> Text -> Maybe Text >> >> Proposal: rename Text.findBy to Text.find. > > I agree with the change of type, not so much with the naming. That's roughly > my stance in the other cases, too. > What would the definition of a function of the form: > find :: (Text -> Bool) -> Text -> Maybe Text look like? What sort of requirements would be placed on the input predicate? Maybe I have a failure of imagination, but that sounds like a tricky thing to get correct for all predicates. Antoine

2 1

Successful library submissions: tickets should include library version
by Claus Reinke 16 Oct '10

16 Oct '10

Currently, the library submissions proccess http://haskell.org/haskellwiki/Library_submissions recommends a link from patch to ticket, but there doesn't seem to be a requirement to link the ticket to the first version of the library that includes the change. For instance, from looking at http://hackage.haskell.org/trac/ghc/ticket/4159 which versions of base and mtl are affected? Claus

1 0

authorspellings
by Bas van Dijk 15 Oct '10

15 Oct '10

Hello, In the current thread about "Making it easier to contribute non-functional changes" Johan Tibell asked about the contributors to the base library. Darcs has a nifty command for this: darcs show authors[1]. This command shows the total number of patches per author. Unfortunately authors email addresses or nicknames change over time which obfuscates this list. Fortunately darcs has a simple way of figuring out which email address or nickname belongs to which author by consulting the .authorspellings file. In this file you can specify the: official author name <official(a)emailaddress.com>, followed by regular expressions for matching old email addresses and nicknames. The attached patch adds an initial .authorspellings file to the base library. It would be nice if somebody could commit it. It would be even nicer still if we could somehow share the same .authorspellings file between GHC and the different boot libraries. Is it possible (and desirable) to create a symlink from the base library to the ghc repositorie's .authorspellings file (which doesn't exist yet). Or maybe we should create a script that synchronizes the different files. Regards, Bas P.S. If you know the real name that belongs to some obscure nickname used in base or if you know which email addresses belong to the same person, please tell, so I can add them. [1] http://darcs.net/manual/Darcs_commands.html#SECTION007103100000000000000

4 5