June 2009 - Libraries

time-1.1.3
by Ashley Yakeley 03 Jun '09

03 Jun '09

The 1.1.3 version of time on Hackage was spuriously uploaded before it was finished and may be buggy. I'll look over it later today and patch it up if necessary. -- Ashley Yakeley

4 11

ANNOUNCE: The Haskell Platform 2009.2.0.1
by Don Stewart 02 Jun '09

02 Jun '09

We're pleased to announce the second release of the Haskell Platform: a single, standard Haskell distribution for everyone. The specification, along with installers (including Windows and Unix installers for a full Haskell environment) are available. Download the Haskell Platform 2009.2.0.1: http://hackage.haskell.org/platform/ The Haskell Platform is a blessed library and tool suite for Haskell distilled from Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Please note that this is a beta release. We do not expect all the installers to work perfectly, nor every developer need met, and we would appreciate feedback. You can help out by packaging the platform for your distro, or reporting bugs and feature requests, or installing Haskell onto your friends' machines. The process for adding new tools and libraries will be outlined in coming weeks. The Haskell Platform would not have been possible without the hard work of the Cabal development team, the Hackage developers and maintainers, the individual compiler, tool and library authors who contributed to the suite, and the distro maintainers who build and distribute the Haskell Platform. Thanks! -- The Platform Infrastructure Team

1 0

Several methods for Data.Sequence
by Louis Wasserman 01 Jun '09

01 Jun '09

This patch contains several methods for Data.Sequence I've always thought were long missing: - scans. This addition is almost trivial with the Traversable instance, but to match properly with the Data.List definitions (which change the length of the output string) requires only a single cons or snoc. - replicate. I don't know why this hasn't been in Data.Sequence already, because with some care, it uses O(log n) memory and amortized time by sharing nodes internally, and that's pretty cool. - zip. This is the one I really wanted to see in Data.Sequence, and I tried out a number of approaches, most of which simply never could work. This implementation truncates the sequences to the same size and then zips from both left and right at once, aligning digits together and handling remainders appropriately. Look at the source for details. More importantly, though, my GHC benchmarks indicate this is oodles faster than the standard workaround -- converting to lists and back. Louis Wasserman wasserman.louis(a)gmail.com

2 1

draft proposal for relative paths in installed package descriptions
by Duncan Coutts 01 Jun '09

01 Jun '09

All, This is a draft proposal for a common mechanism for implementing relative paths in installed package descriptions. Comments and feedback are welcome. I'm cc'ing this to the cabal and ghc-users lists but let's keep the discussion on the libraries list. There has been some discussion of this issue on the cabal and ghc-users list, but it's a relatively long thread and the idea has evolved somewhat so this is an attempt to present the proposal clearly. Proposal ======== This proposal is an extension to the Cabal spec section 3 http://haskell.org/cabal/proposal/x272.html Motivation ---------- Being able to have relative paths in the installed package description is useful as it makes it possible to construct relocatable (prefix-independent) package installations. This is useful when distributing compilers along with packages and there may be other uses. This proposal does not require that all paths are relative. It is still perfectly ok to use absolute paths where appropriate. It just adds an option to use relative paths. The aim is for a single simple specification that any compiler can implement and have the tools work uniformly, rather than ad-hoc implementations for each compiler. Details ------- In the installed package description, we will allow paths that begin with the variables ${pkgroot} or ${pkgrooturl}. For example: library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 They may only appear at the beginning of the paths and must be followed by a directory separator (platform-dependent '/' or '\'). This is because the vars refer to a directory so it does not make sense to construct extensions like ${pkgroot}blah. The use of '{}' is required and is to avoid any ambiguity (especially since the string "$pkgrooturl" is otherwise an extension of "$pkgroot"). Directly relative file paths like "blah" or "./blah" are not allowed. Fields containing paths must be absolute or begin with ${pkgroot}. Field containing urls must be absolute or begin with ${pkgrooturl}. The var ${pkgroot} is to be interpreted as the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is the usual system-dependent filepath syntax, e.g. windows: c:\ghc\ghc-6.12.1 unix: /opt/ghc-6.12.1 The var ${pkgrooturl} is to be interpreted as a url representation of the directory containing the installed package description. For ghc this will be the dir containing the package.conf db, for hugs/nhc for each package there is a specific installed package description file, and ${pkgroot} is thus the directory containing that file. The syntax of the string representing this directory is as a valid file url including the file:// prefix e.g. windows: file:///c:/ghc/ghc-6.12.1 unix: file:///opt/ghc-6.12.1 This is similar to how relative paths in .cabal files are interpreted relative to the directory containing the .cabal file, however in this case we mark relative paths more explicitly using a variable. So in the original example library-dirs: ${pkgroot}/foo-1.0 haddock-html: ${pkgrooturl}/doc/foo-1.0 If we assume this installed package description is at c:\ghc\ghc-6.12.1 \package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then the compiler and other tools would interpret these as library-dirs: c:\ghc\ghc-6.12.1/foo-1.0 haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0 or on unix: library-dirs: /opt/ghc-6.12.1/foo-1.0 haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0 Tools ----- Tools which process the installed package description format will be expected to interpret these relative paths. This requires that they can discover the path for the ${pkgroot}. How they discover this is dependent on the Haskell implementation. Some implementations use separate files for each installed package description, some embed them in library package files, some use databases of installed package descriptions. Haskell implementations should provide a mechanism to discover the path for an installed package description. Duncan

2 2

Proposal: Stop using PackedString in template-haskell; drop packedstring as a bootlib
by Simon Marlow 01 Jun '09

01 Jun '09

Proposal ticket here: http://hackage.haskell.org/trac/ghc/ticket/3270 Deadline for discussion: June 15 (2 weeks) Text of the proposal: The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template-haskell`. The proposal is that we * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change) * change their representation from `PackedString` to `String` * drop the `packedstring` library from the bootlibs that GHC ships with Relevant discussions: * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html]

2 1

Patch to register XmlSyntax and RegularPatterns as known extensions
by Niklas Broberg 01 Jun '09

01 Jun '09

Hi all, I'd like to have concrete XML syntax (HSP) and regular expression pattern syntax (HaRP) registered in Language.Haskell.Extension. The attached patch registers XmlSyntax and RegularPatterns as constructors in the Language.Haskell.Extension.Extension data type, along with haddock documentation. Cheers, /Niklas

4 8