- Libraries - Haskell.org

gnomevfs2
by Ashley Yakeley 13 Aug '07

13 Aug '07

Has anyone created Haskell bindings for gnomevfs2? -- Ashley Yakeley

2 2

Re: patch applied (packages/containers): Remove the rest of base to leave a "containers" package
by ross＠soi.city.ac.uk 13 Aug '07

13 Aug '07

Quoting Ian Lynagh <igloo(a)earth.li>: > Wed Aug 1 15:38:31 PDT 2007 Ian Lynagh <igloo(a)earth.li> > * Remove the rest of base to leave a "containers" package There may be a case for treating the constructor classes (in Data.Foldable and Data.Traversable) differently from the concrete container types (Data.Set et al). For example, to accomodate the instances for Array in the current setup, one of array and containers must depend on the other, although they are not otherwise related. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

5 4

Proposal: Make arrays safer
by Ian Lynagh 10 Aug '07

10 Aug '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1610 This is a proposal to make arrays safer, e.g. see: http://hackage.haskell.org/trac/ghc/ticket/1046 This is a divergence from Haskell 98. The patches: * Add (numElements :: Ix i => a i e -> Int) to IArray class * Array types get an extra field for numElements, e.g. -data UArray i e = UArray !i !i ByteArray# +data UArray i e = UArray !i !i !Int ByteArray# This is a cache of rangeSize(l,u) * Add safeRangeSize (always returns >= 0) * Add safeIndex (use unsafeIndex (no Ix inRange check), but check index < numElements) * unsafeForeignPtrToStorableArray gained an (Ix i) context * Use the new functions in various places Suggested deadline: 24 Aug 2007. Thanks Ian

2 2

"Data.TupleFields" for review
by Samuel Bronson 09 Aug '07

09 Aug '07

Hi. I wrote a module and dons suggested I ask you guys for some tips. Here's a good deal of it: ----------------------------------------------------------------------------- -- | -- Module : Data.TupleFields -- Copyright : (c) 2007 Samuel Bronson -- License : BSD3-style -- -- Maintainer : naesten(a)gmail.com -- Stability : experimental -- Portability : non-portable (multi-param classes, functional dependencies) -- -- -- This module provides tuple field access similar to ML's #1, #2 etc. -- ------------------------------------------------------------------------ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Data.TupleFields where import Data.Tuple class Field1 t f | t -> f where field1 :: t -> f field1_u :: (f -> f) -> (t -> t) field1_s :: f -> (t -> t) field1_s x = field1_u (const x) class Field1 t f1 => Field2 t f1 f | t -> f where field2 :: t -> f field2_u :: (f -> f) -> (t -> t) field2_s :: f -> (t -> t) field2_s x = field2_u (const x) class Field2 t f1 f2 => Field3 t f1 f2 f | t -> f where field3 :: t -> f field3_u :: (f -> f) -> (t -> t) field3_s :: f -> (t -> t) field3_s x = field3_u (const x) class Field3 t f1 f2 f3 => Field4 t f1 f2 f3 f | t -> f where field4 :: t -> f field4_u :: (f -> f) -> (t -> t) field4_s :: f -> (t -> t) field4_s x = field4_u (const x) class Field4 t f1 f2 f3 f4 => Field5 t f1 f2 f3 f4 f | t -> f where field5 :: t -> f field5_u :: (f -> f) -> (t -> t) field5_s :: f -> (t -> t) field5_s x = field5_u (const x) class Field5 t f1 f2 f3 f4 f5 => Field6 t f1 f2 f3 f4 f5 f | t -> f where field6 :: t -> f field6_u :: (f -> f) -> (t -> t) field6_s :: f -> (t -> t) field6_s x = field6_u (const x) class Field6 t f1 f2 f3 f4 f5 f6 => Field7 t f1 f2 f3 f4 f5 f6 f | t -> f where field7 :: t -> f field7_u :: (f -> f) -> (t -> t) field7_s :: f -> (t -> t) field7_s x = field7_u (const x) instance Field1 ((,) t1 t2) t1 where field1 ((,) x1 x2) = x1 field1_u f ((,) x1 x2) = (,) (f x1) x2 instance Field2 ((,) t1 t2) t1 t2 where field2 ((,) x1 x2) = x2 field2_u f ((,) x1 x2) = (,) x1 (f x2) instance Field1 ((,,) t1 t2 t3) t1 where field1 ((,,) x1 x2 x3) = x1 field1_u f ((,,) x1 x2 x3) = (,,) (f x1) x2 x3 instance Field2 ((,,) t1 t2 t3) t1 t2 where field2 ((,,) x1 x2 x3) = x2 field2_u f ((,,) x1 x2 x3) = (,,) x1 (f x2) x3 instance Field3 ((,,) t1 t2 t3) t1 t2 t3 where field3 ((,,) x1 x2 x3) = x3 field3_u f ((,,) x1 x2 x3) = (,,) x1 x2 (f x3) The module goes on to define instances for all the tuple types up through (,,,,,,) (7-tuples). Any suggestions?

3 4

Re: "Data.TupleFields" for review
by Samuel Bronson 09 Aug '07

09 Aug '07

On 8/9/07, Ketil Malde <ketil(a)ii.uib.no> wrote: > On Wed, 2007-08-08 at 22:30 -0400, Samuel Bronson wrote: > > > -- This module provides tuple field access similar to ML's #1, #2 etc. > > Perhaps the naming could be improved? > > Lisp calls these first, second, third, etc and nth for the general case. > (Ignoring the more esoterically named car, cadr, etc, and the fact that > they operate on lists) > > Also, I presume the abbreviations are _u for update, _s for set? Unless > this goes into a standard library (replacing fst and snd?) and thus > becomes ubiquitously used, I'd prefer less cryptic names, perhaps > mapFirst, setSecond, etc. I think 'map' gives the correct connotation, > rather than 'update'. The only convention I'd seen for this when I picked those names was the one that DrIFT implements, so that's what I used. I've since learned that Derive implements a different convention, with names like setFoo where DrIFT would have foo_s, though it doesn't seem to have an equivalent for foo_u. I'm not sure I want map; perhaps some variant of modify... > (Private reply only, as the list won't accept mail from an address the > MUA will let me use. Feel free to cite in public.) How do you know that the list won't accept mail from your address?

1 0

Cabal bug
by Simon Peyton-Jones 04 Aug '07

04 Aug '07

I have not been following the recent work on Cabal, but I tried to build in the gap before this patch was committed. I Fri Aug 3 18:57:01 GMT Daylight Time 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix tab in Cabal.cabal. I was surprised to find that tabs are disallowed in cabal files. Is that really the intention? It seems like a pitfall for the unwary! At the very least, if they must be disallowed, could the error message be more informative? At the moment we get Setup.exe: Cabal.cabal:70: Unrecognized field format: 'Distribution.Simple.SetupWrapper,' It'd be better to get Setup.exe: Cabal.cabal:70: illegal tab character: replace with spaces Simon

3 4

RE: [Haskell-cafe] Definition of the Haskell standard library
by Simon Peyton-Jones 02 Aug '07

02 Aug '07

| On the other hand, it's not entirely true that there's no standard | library, it's just that it's borders are slightly fuzzy. For example, we | do have the library change submission process for modifying the standard | libraries. Up until now that has been taken to mean changes to the base | package. That package is now being split up, so we'll have to think | about what it'll apply to in the future. | | My opinion is that in the past it has been too difficult to get changes | into the base library, that there's been too much stability at the | expense of improving scope and quality. Making it easy to install new | packages and upgrade existing standard libraries should make it easier | to trial more major changes outside of the standard libs before | proposing getting those changes integrated. All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is "blessed"; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the "standard library" is all the X packages. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a "stability" indication, and that might serve, but we'd want to articulate much more clearly what it meant. Simon

5 5

Conditional compilation of Setup.hs
by Bayley, Alistair 31 Jul '07

31 Jul '07

I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ > 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 3

Proposal: Move System.Posix.Signals to the unix package
by Ian Lynagh 30 Jul '07

30 Jul '07

Hi all, Proposal: http://hackage.haskell.org/trac/ghc/ticket/1568 As suggested in http://hackage.haskell.org/trac/ghc/ticket/1190 I propose that the System.Posix.Signals module is moved to the UNIX package. Currently, on Windows, it is an empty module. Suggested deadline: 12 August 2007. Thanks Ian

1 0

Proposal: Move the throwErrnoPath* functions from unix:System.Posix.Error to base:Foreign.C.Error
by Ian Lynagh 29 Jul '07

29 Jul '07

Proposal: http://hackage.haskell.org/trac/ghc/ticket/1566 Currently, unix:System.Posix.Error has a number of throwErrnoPath* functions which are entirely portable, but they are not available on Windows due to being in the unix package. In the thread beginning http://www.haskell.org/pipermail/libraries/2007-July/007793.html Simon Marlow writes: When I needed to add some error-related functionality for the POSIX library, I didn't want to add extra stuff to Foreign.C.Error beyond what was specified in the FFI spec, so I added System.Posix.Error instead. This was just conservative; we could probably add throwErrnoPath and friends to Foreign.C.Error (with the usual proposal process). I propose that these functions are moved to base:Foreign.C.Error. They would still be re-exported by unix:System.Posix.Error to minimise breakage. Suggested deadline: Sun 12 August 2007. Thanks Ian

2 1