February 2005 - Libraries

ANN: Cabal 0.5 (GHC 6.4 release candidate)
by Isaac Jones 22 Feb '05

22 Feb '05

This is a release-candidate for 0.6, which will be in GHC 6.4. http://www.haskell.org/cabal/download.html The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage. The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to libraries(a)haskell.org and Isaac Jones: ijones(a)syntaxpolice.org. ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with "./Setup.lhs" since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/

3 4

ANN: Hacanon 0.1
by Lemmih 21 Feb '05

21 Feb '05

What is Hacanon? Hacanon is a Template Haskell library which automates the process of binding Haskell to libraries written in C++. It's designed to capture common patterns and allow the programmer to specify the desired behaviour accordingly. Hacanon is capable of generating a usable binding, without any interaction, to almost any piece of C++. This binding is of relatively high level, because Hacanon translates enumerations to Haskell data structures, has transparent callback support and overloads every function. Unfortunately, such a binding would, in most cases, be flawed. Is 'int*' an array, variable which holds a second result or something third? Here Hacanon provides a data interface scheme (aka DIS) system which allows the programmer to concisely describe how an argument should be handled. DISs can be derived from other DISs because they're nothing more than data structures. This gives rise to increased code reuse and minimizes the burden on the programmer. These DISs can be used in the appliance system where the programmer can guard on function name (via regex), argument type and argument number. Some of the features sound familiar. Is Hacanon related to GreenCard or HDirect? I've borrowed the DIS concept from GreenCard and directional arguments from HDirect. I would like to think I've taken the best of both worlds and added some innovation in form of automation. Dependencies: * Recent version of GHC. Tested with ghc-6.4.20050209 and ghc-6.4.20050219. http://www.haskell.org/ghc * HaXml 1.12. http://www.cs.york.ac.uk/fp/HaXml/ * GCCXML from CVS hacked to include template information. Hack is distributed with Hacanon. Author and availability: Hacanon is written by David Himmelstrup and published under a MIT-style license. Darcs repository: http://www.scannedinavian.org/repos/hacanon/ -- Friendly, Lemmih

2 2

Related work on timezones/calendars/etc
by Graham Klyne 21 Feb '05

21 Feb '05

Very loosely apropos the time library discussion, there's some related activity concerning timezones. I cite below a particular message [1] from Dan Connolly (W3C), because he's very good at placing links to other relevant resources in his messages... [1] http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0009.html #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

[announce] Fedora Haskell mailing list
by Jens Petersen 21 Feb '05

21 Feb '05

The Fedora Haskell project now has a mailing list which is kindly hosted on haskell.org. :) If you wish to subscribe for announcements and discussion of packaging Haskell projects for Fedora, please go to <http://haskell.org/mailman/listinfo/fedora-haskell>. More information about the project is available on <http://haskell.org/fedora> Cheers, Jens

1 0

RE: Newtypes in Time Libraries
by Simon Marlow 21 Feb '05

21 Feb '05

On 18 February 2005 23:44, Ashley Yakeley wrote: > What sort of functions should be provided to access certain newtypes? > For instance, consider this: > > newtype DiffTime = MkDiffTime Integer -- picoseconds > > It's considered good practice to hide MkDiffTime. At the same time, I > need to provide access to the underlying value, so I provide these: > > timeToSISeconds :: (Real a) => DiffTime -> a > > siSecondsToTime :: (Real a) => a -> DiffTime > > These convert with picoseconds by multiplication or division. But do I > also want to provide access to the picoseconds directly? > > timeToSIPicoseconds :: DiffTime -> Integer > timeToSIPicoseconds (MkDiffTime ps) = ps > > siPicosecondsToTime :: Integer -> DiffTime > siPicosecondsToTime = MkDiffTime > > This makes certain other calculations in other modules easier. > > I have a similar issue with TimeZones. My intention is to encode them > as a count of minutes, hide the constructor, but provided > minutesToTimeZone and timeZoneToMinutes. Is this sensible? I like to just provide instance Integral and document that the type is an integral number of picoseconds. It means you can use overloaded constants, and the usual arithmetic operations on DiffTime. Cheers, Simon

1 0

Language.Haskell.Parser and layout rules
by Mirko Rahn 18 Feb '05

18 Feb '05

The function Language.Haskell.Parser.parseModule behaves somehow strange and disagrees with ghc-6.* about the set of accepted inputs. An example: -- file T1.hs: main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps -- file T2.h2 main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps Note the difference is an additional whitespace in T2. I think both codes are perfectly valid, but parseModule fails on T1. Is anyone able to explain why? Thanks, Mirko Rahn ---- mirak@loop:~> ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.20050211, for Haskell 98

5 5

Newtypes in Time Libraries
by Ashley Yakeley 18 Feb '05

18 Feb '05

What sort of functions should be provided to access certain newtypes? For instance, consider this: newtype DiffTime = MkDiffTime Integer -- picoseconds It's considered good practice to hide MkDiffTime. At the same time, I need to provide access to the underlying value, so I provide these: timeToSISeconds :: (Real a) => DiffTime -> a siSecondsToTime :: (Real a) => a -> DiffTime These convert with picoseconds by multiplication or division. But do I also want to provide access to the picoseconds directly? timeToSIPicoseconds :: DiffTime -> Integer timeToSIPicoseconds (MkDiffTime ps) = ps siPicosecondsToTime :: Integer -> DiffTime siPicosecondsToTime = MkDiffTime This makes certain other calculations in other modules easier. I have a similar issue with TimeZones. My intention is to encode them as a count of minutes, hide the constructor, but provided minutesToTimeZone and timeZoneToMinutes. Is this sensible? -- Ashley Yakeley, Seattle WA

1 0

Cabal problems with an executable containing c-sources
by Einar Karttunen 18 Feb '05

18 Feb '05

Hello The following case seems to be broken: Name: tt Version: 0.0 License: BSD3 Executable: tt Main-Is: test.hs C-Sources: a.c Extensions: ForeignFunctionInterface a.c is completely ignored by Cabal. A complete minimal example can be found at: http://www.cs.helsinki.fi/u/ekarttun/haskell/executable-with-c-sources.tar.… - Einar Karttunen

3 5

RE: Minor changes in the package description syntax
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 15:42, Isaac Jones wrote: > Krasimir Angelov <kr.angelov(a)gmail.com> writes: > >> Hello Guys, >> >> In the package description syntax are used ld-options and cc-options >> fields. In the same time the Haskell compiler options are options-ghc >> and options-hugs. Is there any objections to rename them to >> ghc-options and hugs-options? This is only better naming convention. > > I have no objections if it's not too late for GHC 6.4. Yes, fine by me. Simon

1 0

Minor changes in the package description syntax
by Krasimir Angelov 17 Feb '05

17 Feb '05

Hello Guys, In the package description syntax are used ld-options and cc-options fields. In the same time the Haskell compiler options are options-ghc and options-hugs. Is there any objections to rename them to ghc-options and hugs-options? This is only better naming convention. Cheers, Krasimir

2 1