May 2010 - Libraries - Haskell.org

proposal #4095: add Applicative instance for Either
by Ross Paterson 26 May '10

26 May '10

The proposal is to add this instance to Control.Applicative: instance Applicative (Either e) where pure = Right Left e <*> _ = Left e Right f <*> r = fmap f r This is not the only possible instance for Either, but this one is compatible with the usual Monad instance. Deadline: 15th June 2010

8 18

Text.Regex library with bytestrings?
by Kathleen Fisher 24 May '10

24 May '10

Is it possible to use the Text.Regex API with ByteStrings instead of Strings? It looks like there is support for using PCREs with either Strings and ByteStrings, but if you want to use the high-level API in Text.Regex (ie, mkRegex, matchRegexAll, etc), you have to use Strings. For Bytestrings, you can use the lower level API in Text.Regex.Posix.ByteString, but then you are in the IO monad, which I'd rather avoid. Am I missing something? Thanks for any pointers! Kathleen

1 0

ANN: Enhancements to timezone processing in Data.Time
by Yitzchak Gale 24 May '10

24 May '10

The new timezone-series and timezone-olson packages provide enhancements to timezone processing in Haskell's time package, Data.Time. http://hackage.haskell.org/package/timezone-series http://hackage.haskell.org/package/timezone-olson These enhancements are related to the fact that the Data.Time.TimeZone data type does not fully represent a timezone - it only represents a specific clock setting for a timezone, as is traditional for time APIs. But that leads to a number of limitations, such as: o For utcToLocalTime and localTimeToUTC, it is up to the user to ensure that the TimeZone and time specified are consistent with each other. These functions can give wrong results if the specified clock setting was not actually in effect at the specified moment in the given timezone. o It is difficult to compute the amount of time between two moments expessed in terms of the local clock, because you need to know the history of clock changes that happened in between. o When a ZonedTime is constructed, it is up to the user to ensure that its components are consistent with each other and make sense. o Given a ZonedTime, there is no way to construct another ZonedTime for a different moment in the same timezone, unless you know that the same clock setting is in effect at the new moment. Besides those issues - it's just nice to have a type that truly models a timezone. The timezone-series package introduces two new datatypes: TimeZoneSeries, which represents a timezone with all of its clock settings and when each is in effect, and ZoneSeriesTime, which represents a moment within a specific timezone. This package also includes variants of utcToLocalTime and localTimeToUTC which take a TimeZoneSeries instead of a TimeZone as parameter and always give the correct result. The timezone-olson package provides a pure Haskell parser and renderer for binary Olson timezone files. That provides an easy way to create rich TimeZoneSeries objects for most of the timezones of the world on many platforms. I have tried to write these packages in a way that is consistent as much as possible with Data.Time - naming conventions, providing expected services such as ParseTime and FormatTime instances, etc. These packages are distributed on Hackage under a BSD3 license. Caveats: o These packages contain preliminary versions of the software and should be considered highly experimental. Expect there to be bugs, and do not rely on any stability of the exposed interfaces at the moment. o So far, there is no easy solution for Windows users to create a TimeZoneSeries. On Windows, timezone series information is in the registry in a propreitary format, and I don't have a parser for that at the moment. In the meantime, Windows users can copy the Olson files from a Unix system, or compile the Olson files themselves from the zoneinfo sources. I hope to have a much better solution in the near future, and, of course, contributions are welcome. o There is not yet a truly platform-independent way of finding the Olson files for Unix-like platforms. Nowadays /usr/share/zoneinfo is a very popular location for them, but some platforms have them elsewhere. o getCurrentTimeZone is still the best way to get the "official" clock setting for the current moment on the local computer for the local time zone, or for whatever time zone you fool the OS into thinking that you are in. There is also Mark Aylett's zoneinfo package. Those bindings to the C API give you clock settings that are most likely to be consistent with what is used by other apps on the same local computer. But the C API gives you a clock setting, not a timezone. And the system timezone database on the local computer could be out of date. And the interface, which involves setting global process state and then calling effectful procedures, is awkward to say the least and prone to cause trouble. So I think it's nice to have a pure Haskell Olson parser. I would like to take this opportunity to thank once again Ashley Yakely for his fantastic work in creating Haskell's advanced time API in Data.Time. Enjoy, Yitz

2 1

Cabal sqlite3 installation problems
by Hok Shun Poon 23 May '10

23 May '10

Hello, This is a question about how cabal-install finds 'installed foreign libraries' when trying to satisfy dependencies for packages like hdbc-sqlite3 on Windows. Sadly, the current setup means that I must use Windows 7 to develop code. I've already followed steps on http://wiki.github.com/jgoerzen/hdbc/frequentlyaskedquestions to place the .dll and the .h files in the correct places; it's just that cabal never seems to find it, despite being given --extra-lib-dirs= and --extra-include-dirs= directives. The message is as follows: > cabal install hdbc-sqlite3 --extra-lib-dirs=D:\dev\libs\database\sqlite Resolving dependencies... Configuring HDBC-sqlite3-2.3.0.0... cabal: Missing dependency on a foreign library: * Missing C library: sqlite3 This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: HDBC-sqlite3-2.3.0.0 failed during the configure step. The exception was: ExitFailure 1 The strangest thing is, I've successfully made cabal build this package before (with a different version of Haskell Platform)... what's going on? I'm using cabal-install version 0.8.2 and Cabal library version 1.8.0.2. Hok

1 0

memory useage of data types in the time package
by Duncan Coutts 23 May '10

23 May '10

Hi Ashley (and other people interested in the time lib), I wonder if we could look more closely at the in-memory representations of the data types in the time library to see if we could make them a bit smaller. There are various sorts of programs that deal with a large quantity of data and often that includes some date/time data. It's a great shame that programs dealing with lots of time data might have to avoid using the time package and revert to things like newtype Seconds = Seconds Int32 simply because they take less space, and can be unpacked into other data structures. Looking at the representations in the time package, I think there are a number of places where the size could be reduced without affecting the behaviour or significantly affecting the range of values that can be represented. For example, data TimeOfDay = TimeOfDay { todHour :: Int, todMin :: Int, todSec :: Pico } This uses 40 bytes (or 80 bytes on 64bit) but it could be brought down to just 20 bytes (or 24 on 64bit). We could use strict fields here for the Ints and build the package with -funbox-strict-fields. This would save 4 words. The most expensive one here is Pico which uses an Integer underneath and thus cannot be unboxed. We could save a further two words if Pico were based on Int64 instead of Integer. In principle, the hour and minutes could be Int16 and perhaps in future ghc might be able to pack them into a single word inside the TimeOfDay record. If we find cannot change Pico (since it's in the base package), then we could change the time package to use some equivalent fixed point type. newtype Day = ModifiedJulianDay {toModifiedJulianDay :: Integer} This could use Int64 without significantly affecting the range. It would still let us represent dates trillions of years into the future or past. (Using Int32 would allow dates a mere few million years in the future). Again, the point of using Int64 is to save an indirection and to allow the type to be unboxed into other constructors such as: data UTCTime = UTCTime { utctDay :: Day, utctDayTime :: DiffTime } This takes 7 words, 28 or 56 bytes. It could be reduced to 20 or 24 bytes. This one is especially useful to make smaller since it is used as a timestamp in many applications, so there tend to be a lot of them. newtype DiffTime = MkDiffTime Pico Again, Pico based on Int64 rather than Integer would save space, save an indirection and allow further unboxing. In general, do any of the date/time record types need to have lazy fields? My guess is that they do not. Duncan

7 8

unix package patch to add support for setting effective uid/gid
by Eric Mertens 17 May '10

17 May '10

Hello, I believe that it would be useful for the unix package to support setting the effective user-id and group-id of a process. By setting the effective id instead of the real id you can toggle between real and set-user-id. It seems like a simple oversight that these functions have been left out of the unix package. I have attached the darcs patch for these function. This patch does not explicitly bump the version number as I thought it might be integrated with other patches before a new release (That could be wrong). -- Eric Mertens <emertens(a)galois.com> Galois, Inc.

2 1

turning ExitCode into an IO exception
by Henning Thielemann 11 May '10

11 May '10

Is there a prefered way to convert an ExitCode to an IO exception? When running a sequence of IO actions, it is certainly best to use the same way of showing failure for all of them. However running shell commands with functions from the 'process' package shows failure by ExitCode which is different from almost all other IO actions in 'base'.

2 1

Haskell 2010 libraries
by Simon Marlow 09 May '10

09 May '10

Hi Folks, I'm editing the Haskell 2010 report right now, and trying to decide what to do about the libraries. During the Haskell 2010 process the committee agreed that the libraries in the report should be updated, using the current hierarchical names, adding new functionality from the current base package, and dropping some of the H'98 library modules that now have better alternatives. In Haskell 2010 we're also adding the FFI modules. The FFI addendum used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are usually known by their hierarchical names nowadays: e.g. Foreign.C, Foreign.Marshal.Alloc. It would seem strange to add the non-hierarchical names to the Haskell language report. So this is all fine from the point of view of the Haskell report - I can certainly update the report to use the hierarchical module names, but that presents us with one or two problems in the implementation. The obvious thing to do would be to make a haskell2010 package that re-exports the appropriate modules from base, providing a fixed API that people can depend on when they write Haskell 2010 code. However, what happens when someone wants to write some code that uses Haskell 2010 libraries, but also uses something else from base, say Control.Concurrent? The modules from haskell2010 overlap with those from base, so all the imports of Haskell 2010 modules will be ambiguous. The Prelude is a bit of a thorny issue too: currently it is in base, but we would have to move it to haskell2010. Bear in mind these goals: we want to a. support writing code that is Haskell 2010 only: it only uses Haskell 2010 language features and modules. b. not break existing code as far as possible c. whatever we do should extend smoothly when H'2011 makes further changes, and so on. Here are some non-options: 1. Not have a haskell2010 package. We lose (a) above, and we lose the ability to add or change the API for these modules, in base, since they have to conform to the H'2010 spec. If H'2011 makes any changes to these modules, we're really stuck. 2. As described above: you can either use haskell2010, or base, but not both. It would be painful to use haskell2010 in GHCi, none of the base modules would be available. Here are some options: 3. allow packages to shadow each other, so haskell2010 shadows base. This is a tantalising possibility, but I don't have any idea what it would look like, e.g. should the client or the package provider specify shadowing? 4. Provide a haskell2010 package and a base2010 package that re-exports all of base except the modules that overlap with haskell2010. You can either use haskell2010, haskell2010+base2010, or base. This is a bit like (1), but avoids the need for shadowing by using package re-exports, on the other hand confusion could well arise due to the strange base2010 package, and some people would surely try to use haskell2010 + base and run into difficulties. 5. Not have a haskell2010 package, but have the report say that implementations are allowed to add things to the standard libraries. Thoughts? Better ideas? Cheers, Simon

13 20

ANNOUNCE: network-protocol-xmpp 0.3
by John Millikin 07 May '10

07 May '10

XMPP[1] is a protocol for asynchronous communication via long-lived XML documents. It is most famous for underlying the Jabber and Wave protocols, but is also used for a variety of cases where security and extensibility are useful. My library, network-protocol-xmpp[2], is an implementation of most of RFC 3920 and a bit of RFC 3921. It supports opening client-to-server and component-to-server sessions, which is useful for implementing XMPP-based clients. This library's interface is very simple: clients may start a session with 'runClient' or 'runComponent', send and receive stanzas, and resume stored sessions. Later, I intend to add additional modules to support features such as MUC or file transmission, but for now I'd like to make sure the core library works. There's an example XMPP client, echo.hs[3], in the Darcs repository. Server-to-server sessions and accepting connection requests are not yet supported, so it's not usable as the foundation of an XMPP server yet. However, given that XMPP prefers to place features on the servers rather than clients, it's likely that writing an XMPP server in Haskell would take a *lot* of effort anyway. You're probably better off just using ejabberd or OpenFire. My thanks go to Stephan Maka, who let me know that this library actually has users, and who contributed most of the Component connection implementation. ---------- Additionally, I'm trying an experiment intended to break the gridlock of Haskell XML libraries. Currently, there are multiple options for XML handling (HXT, HaXml, libxml, tagsoup, xml, xml-basic) but each defines their own data types. This makes it very difficult to mix-and-match -- I can't easily use one library's parser with another's tree manipulation combinators. Simple use cases, such as using HXT for serializing, drag in dozens of dependencies on libraries like HTTP and QuickCheck. A library's poor data type definitions (such as HaXml's lack of support for namespaces) means that an entire set of potentially useful operations is unusable. And a library's choice propagates! In n-p-xmpp 0.2, which used HXT, clients were forced to figure out arrows before they could perform even rudimentary inspection of received stanzas. To fix this, I've created the xml-types[4] package. Its only dependency is the "text" library, and it defines full types for most XML structures[5]. My hope is that other libraries will replace their own types with these, so that (for example) I can parse events with libxml, manipulate them with HXT's arrow API, and write them back out using a custom serialiser without having to jump through type conversion hoops. It might take some time before any major XML libraries are transitioned to these types, but maybe in a year or two there'll be enough to be useful. [1] http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol [2] http://hackage.haskell.org/package/network-protocol-xmpp [3] http://patch-tag.com/r/jmillikin/xmpp/snapshot/current/content/pretty/examp… [4] http://hackage.haskell.org/package/xml-types [5] I haven't included types for inner entity declarations in DTDs, out of laziness, because does anybody actually *use* those?

2 1

darcs patch: Correct haddock formatting.
by Adam Vogt 06 May '10

06 May '10

1 patch for repository http://darcs.haskell.org/packages/base: Thu Apr 22 22:21:03 EDT 2010 Adam Vogt <vogt.adam(a)gmail.com> * Correct haddock formatting.

2 1