November 2008 - Libraries

ByteString, foldr and lazyness
by Mathieu Boespflug 29 Nov '08

29 Nov '08

Hi all, Here's a ghci session, using bytestring-0.9.1.4 and ghc-6.10: Prelude> :m Data.ByteString.Lazy.Char8 Prelude Data.ByteString.Lazy.Char8> :m -Prelude Data.ByteString.Lazy.Char8> foldr (:) [] (concat (Prelude.repeat "a")) Loading package bytestring-0.9.1.4 ... linking ... done. "*** Exception: stack overflow By contrast, using Prelude's foldr and concat: Prelude> foldr (:) [] (concat (repeat "a")) :: String <prints out an infinite list> Each bytestring chunk only contains one letter, so I would expect the foldr of bytestring to behave just like that of the Prelude. Is this a bug? A feature? From looking at the bytestring source code I don't see why the code behaves this way. Many thanks, Mathieu

3 3

Why isn’t (>>>) a method?
by Wolfgang Jeltsch 27 Nov '08

27 Nov '08

Hello, I wonder why (>>>) is an ordinary function instead of a method with a default implementation based on (.). The latter would make life easier in two ways. First, it would be easier to write code which works with the old Arrow class and the new Category/Arrow solution (fewer CPP stuff). Second, I often find it easier to “think forwards” and use (>>>) instead of “thinking backwards” and using (.). So it would be nicer for me to use (>>>) in a method implementation instead of (.). Best wishes, Wolfgang

5 5

Ann: Version 1.2.1 of Protocol-Buffers for Haskell
by Chris Kuklewicz 27 Nov '08

27 Nov '08

This is to announce version 1.2.1 of my protocol-buffers, protocol-buffers-descriptor, and hprotoc packages. Note: Code generated by the previous versions of hprotoc will not work with this new version of the library, and vice-versa. These improve on the previous version 1.0.1 in a few ways: * The Enum modules have a new "toMaybe'Enum :: Int -> Maybe TYPE" function which allows for better error handling. * The generated Enum instances have better error messages. * The wireGet deserialization operation on Messages and Groups has better error handling: ** Unrecognized enum value call throwError instead of calling error. ** Incoming strings are checked for valid utf8 encoding, or will call throwError. ** For messages generated with "unknown" support, all field error are caught and then the data is loaded into the unknown map (which might also fail, which won't be caught). * wireGet now uses explicitly generated "Set WireTag" instead of using reflection. This is saner, and might even have helped performance. * A bug inside an error reporting function in hprotoc was fixed (it caused a hang due to lazy self-dependence when showing error information). The main upside to these changes is to remove a the "error" call from 1.0.1's used of toEnum and make the deserialization more robust and predictable. In the future there will be support for the changes in google's upcoming version 2.0.3 of protoc (mainly custom EnumValue options). Cheers, Chris

1 0

Data Parallel Haskell
by James Swaine 26 Nov '08

26 Nov '08

Does anyone know if this library is being actively maintained? We had some trouble getting it to build with the 6.10 sources, and it didn't look it had been updated in a while, so I guess I just wanted to check and see if anyone knew about it. Thanks all! James

4 8

Arch Haskell News: Nov 23 2008
by Don Stewart 24 Nov '08

24 Nov '08

News about Haskell on Arch Linux * Arch now has 734 Haskell packages now * That’s an increase of 29 new packages in the last 8 days! * 3.6 new Haskell releases are occuring each day. Noteworthy, * haskell-hledger-0.2: “A ledger-compatible text-based accounting tool.” * gitit-0.3.1: “Wiki using HAppS, git, and pandoc.” * lhc-20081121: “Lhc Haskell Compiler” * haskell-hosc-0.6: “Haskell Open Sound Control” * haskell-flickr-0.3.2: “Haskell binding to the Flickr API” * haskell-delicious-0.3.2: “Accessing the del.icio.us APIs from Haskell (v2)” * haskell-mediawiki 0.2.3: “Interfacing with the MediaWiki API” * darcs-2.1.2.2: “a distributed, interactive, smart revision control system” Full update list, http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/ -- Don

1 0

base-3.0.3.0 not backwards compatible with base-3.0.2.0
by Stefan Holdermans 20 Nov '08

20 Nov '08

Hi all, Could anyone confirm the following claims? * base-3.0.3.0 (shipped with GHC 6.10.1) is supposed to be backwards compatible with base-3.0.2.0 (shipped with GHC 6.8.3) ... * ... but it isn't! (For example, the Arrow class from Control.Arrow is a subclass of Category from Control.Category in base-3.0.3.0, but not in base-3.0.2.0.) Do we know of any similar issues? What's the recommended workaround when shipping code that is to support both GHC 6.8.* and GHC 6.10.*?) Thanks, Stefan

2 1

problem in installing readline
by Gyesik Lee 18 Nov '08

18 Nov '08

Hello, I am really sorry for bothering you with this kind of question, but I here have no one to ask about readline. Indeed I am trying to install Agda which requires readline 1.0.1.0. But I can neither use cabal nor install it manually. Here are the error messages. It would be really nice if you could give some advices. Thank you very much in advance. Best regards, Gyesik ============= dhcpa11098:Agda leegy$ sudo cabal install readline Password: Resolving dependencies... 'readline-1.0.1.0' is cached. Configuring readline-1.0.1.0... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for GNUreadline.framework... checking for readline... no checking for tputs in -lncurses... yes checking for readline in -lreadline... yes checking for rl_readline_version... yes checking for rl_begin_undo_group... no configure: error: readline not found, so this package cannot be built See `config.log' for more details. cabal: Error: some packages failed to install: readline-1.0.1.0 failed during the configure step. The exception was: exit: ExitFailure 1

4 3

darcs patch: filling out the extensible exceptions library
by Judah Jacobson 17 Nov '08

17 Nov '08

Hi all, Attached are some patches for the extensible-exceptions library, which lets packages use the new exceptions API portably on all versions of ghc (well, at least as far back as 6.6.1, from my tests). To summarize: I filled out the API by copying all of the missing functions from base4:Control.Exception, and edited the .cabal file to make 'cabal install extensible-exceptions' do the right thing. Also, I'm eager to have this package on hackage so that I can start using it in my own libraries; let me know if there's anything else I could do to work towards that goal. Thanks, -Judah Sun Nov 16 09:52:02 PST 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Bump the library version to 0.1.1.0. M ./extensible-exceptions.cabal -1 +1 Sat Nov 15 16:49:25 PST 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Copy all of the missing functionality/documentation from base4:Control.Exception. M ./Control/Exception/Extensible.hs -21 +358 Sat Nov 15 16:47:04 PST 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Update the package description in the .cabal file. M ./extensible-exceptions.cabal -4 +2 Sat Nov 15 10:59:27 PST 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Hide some functions which are not possible to implement under the old API. M ./Control/Exception/Extensible.hs -1 +1 Sat Nov 15 10:52:57 PST 2008 Judah Jacobson <judah.jacobson(a)gmail.com> * Use Cabal flags to select which version of Control.Exception to build on top of. This ensures that cabal-install will use the correct version of base. M ./Control/Exception/Extensible.hs -1 +1 M ./extensible-exceptions.cabal -1 +5

2 1

Splitting SYB from the base package in GHC 6.10
by José Pedro Magalhães 17 Nov '08

17 Nov '08

Hello all, I'm initiating this discussion per suggestion of SP Jones and following from [1]. The issue is: SYB is being moved out of base into its own package. However, the Data class is, in a way, tied to base since it depends on the deriving mechanism. Therefore, it was suggested that the entire Data.Generics.Basics module [2] should remain in base. This module defines the Data class and several associated functions and datatypes. I don't think anyone objected to this so far: please correct me if I'm wrong, or object now. Then it was also suggested that Data.Generics.Instances [3] could stay in base (perhaps inside Basics as well). This, however, would prevent dealing with the "dubious" Data instances [4], and this was one of the motivating factors to split SYB from base. This refers concretely to the instances: instance (Data a, Data b) => Data (a -> b) instance Typeable a => Data (IO a) instance Typeable a => Data (Ptr a) instance Typeable a => Data (StablePtr a) instance Typeable a => Data (IORef a) instance Typeable a => Data (ForeignPtr a) instance (Typeable s, Typeable a) => Data (ST s a) instance Typeable a => Data (TVar a) instance Typeable a => Data (MVar a) instance Typeable a => Data (STM a) instance (Data a, Integral a) => Data (Ratio a) These instances are defined in such a way that they do not traverse the datatype. In fact, there is no other possible implementation, and this implementation at least allows for datatypes which contain both "regular" and "dubious" elements to still have their "regular" elements traversed. However, this implies that a user cannot redefine such instances even in the case where s/he knows extra information about these types that would allow for a more useful instance definition, for instance. Claus, please correct me if I'm wrong, but if the 11 "dubious" instances (or perhaps less, given your message in [5]) go in the syb package and the remaining, "standard" ones stay in base, we: - Mantain backwards compatibility regarding SYB in 6.10, and - Can still deal with the issue by releasing a new version of the syb package later, independently of GHC. Since the deadline for 6.10 is approaching I'm assuming that we should try to minimize the changes there, while keeping future development in the syb package as open as possible. Finally, there are module naming issues, which are probably secondary to the issue above and can be dealt with separately and later. Thanks, Pedro [1] The base library and GHC 6.10: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9929 [2] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-Ba… [3] http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Data-Generics-In… [4] http://www.haskell.org/pipermail/generics/2008-June/000347.html [5] http://article.gmane.org/gmane.comp.lang.haskell.libraries/9957

11 46

Proposal #2769: Export mapAccumR from Data.Map, Data.IntMap
by Matti Niemenmaa 16 Nov '08

16 Nov '08

Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2769 Discussion period: 1 week The `mapAccumR` function has been written in both the Data.Map and IntMap sources but it's commented out and not exported. This seems to be an error and I propose that it be simply uncommented. The issue can be worked around by using Data.List.mapAccumL on the descending list representation of the Map, but that's hardly optimal. Seems like a no-brainer to me, hence the short discussion period.

2 2