- Libraries - Haskell.org

extensible-exceptions configuration failure, ghc 6.8.1, cabal 1.2.2.0
by Anton Tayanovskyy 14 Mar '09

14 Mar '09

Hi, extensible-exceptions-0.1.1.0 # runghc Setup.hs configure Setup.hs: extensible-exceptions.cabal:21: Parse of field 'extensions' failed: It builds fine after upgrading cabal to 1.6; probably the correct dependency on cabal version is somewhere in between 1.2 and 1.6 Thanks, --A

1 0

UArray for newtypes (LogFloat)
by Felipe Lessa 09 Mar '09

09 Mar '09

Hello, So, I would like to make an UArray of LogFloat. They are a newtype of Double, but the type system can't see trough newtypes. So I wonder if it is acceptable to exploit the fact that the internal representation of newtypes don't change to use some safe unsafeCoerces and create an instance of IArray for UArray of LogFloat. I've looked at the core of the code below and it seems sane, and -Wall only warn about the orphan instance, so I would also like to ask to include this instance in logfloat package itself (I've sent a copy of this message to LogFloat's maintainer). {-# LANGUAGE MultiParamTypeClasses #-} import Data.Array.Base import Data.Array.Unboxed (UArray) import Data.Number.LogFloat import Unsafe.Coerce -- For testing below import Data.Array.Unboxed as U import Test.QuickCheck {-# INLINE from #-} from :: UArray a LogFloat -> UArray a Double from = unsafeCoerce {-# INLINE to #-} to :: UArray a Double -> UArray a LogFloat to = unsafeCoerce {-# INLINE func #-} func :: (LogFloat -> a -> LogFloat) -> (Double -> a -> Double) func = unsafeCoerce instance IArray UArray LogFloat where {-# INLINE bounds #-} bounds = bounds . from {-# INLINE numElements #-} numElements = numElements . from {-# INLINE unsafeArray #-} unsafeArray lu = to . unsafeArray lu . unsafeCoerce {-# INLINE unsafeAt #-} unsafeAt = unsafeCoerce . unsafeAt . from {-# INLINE unsafeReplace #-} unsafeReplace arr = to . unsafeReplace (from arr) . unsafeCoerce {-# INLINE unsafeAccum #-} unsafeAccum f arr = to . unsafeAccum (func f) (from arr) {-# INLINE unsafeAccumArray #-} unsafeAccumArray f initialValue lu = to . unsafeAccumArray (func f) (unsafeCoerce initialValue) lu test1 :: [Double] -> Bool test1 elms' = elms == U.elems arr where arr :: UArray Int LogFloat arr = U.listArray (1, length elms) elms elms = map (logFloat . abs) elms' test2 :: [Double] -> Bool test2 elms' = product elms == arr U.! 1 where arr :: UArray Int LogFloat arr = U.accumArray (*) 1 (1, 1) [(1,x) | x <- elms] elms = map (logFloat . abs) elms' main :: IO () main = quickCheck test1 >> quickCheck test2 -- Felipe.

3 2

ANN: Future 1.1.0 concurrency library
by ChrisK 09 Mar '09

09 Mar '09

Hello, As a side effect of the discussion of the new C++ future/promise features at http://lambda-the-ultimate.org/node/3221 I have implemented a Haskell package called "future" at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future This ought to do what C++ standard futures/promises do, plus a bit more. The main operation is > forkPromise :: IO a -> IO (Promise a) This sets the "IO a" operation running in a fresh thread. The eventual result can be accessed in many ways (non-blocking, blocking, blocking with timeout). > let one :: Int; one = 1 > p <- forkPromise (return (one+one)) > x <- get > y <- wait x is an Int with value 2. y is an (Either SomeException Int) with value (Right 2). The useful thing about futures, as opposed to various IVar packages, is handling the case where the forked operation ends with an exception. The exception becomes the return value of the promise. The "get" operation rethrows it, the "wait" operation returns it as (Left ...). There is also an "abort" command to kill a promise. The dead promise may then have an exceptions as its value. The "plus a bit more" than C++ is the nonblocking "addTodo" feature. This takes a continuation function from the "Either SomeException a" to an IO operation. These continuation functions get queued and they are run immediately after the the forked operation completes. Once completed any new "addTodo" continuations run immediately. These continuations allow you to race a list of action and take the first one done, or to collect the answers as they complete into a Chan. Both of those options are demonstrated in Future.hs as racePromises and forkPromises. It should be safe to use "unsafePerformIO . get" or "unsafePeformIO . wait" to get lazy access to the result, which is itself immutable once set. Cheers, Chris

2 1

Re: UArray for newtypes (LogFloat)
by Felipe Lessa 08 Mar '09

08 Mar '09

On Sat, Mar 7, 2009 at 9:10 PM, wren ng thornton <wren(a)freegeek.org> wrote: > You can replace many of the coercions by using logToLogFloat and > logFromLogFloat. Those give an isomorphism without doing log/exp, which is > specialized for Double to be id (except logToLogFloat also checks isNaN). I used unsafeCoerce for saving the check cost as we know it is valid. > Though, as a general matter it seems that adding "deriving (IArray UArray)" > to the newtype declaration is sufficient. Doesn't even require > GeneralizedNewtypeDeriving. I'll push out a new release soon. Whoa, that's great news for me, didn't know it was possible. And thanks for acting so promptly. :) -- Felipe.

1 0

Re: [Haskell] string type class
by Brandon S. Allbery KF8NH 06 Mar '09

06 Mar '09

On 2009 Mar 6, at 11:13, Wolfgang Jeltsch wrote: > Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock: >> It seems every time I look at hackage there is yet another stringy >> datatype. For lots of apps, the particular stringy datatype you use >> matters >> for performance but not algorithmic reasons. Perhaps this is a good >> time >> for someone to propose a stringy class? > > There is already the class IsString which was introduced for > overloaded string > literals. > > However, the name is terrible. No other Haskell class I know of has > an “Is” at > its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…). But their proper names were available. "String" is already taken for a concrete type, which complicates things; "IsString" was the simplest answer (and possibly avoided bikeshedding by being the answer nobody liked :) > Maybe you can also try to convince the masters of the IsString class > to change > the class name. My previous attempts through mailing list e-mails > seemed to > have no effect. :-( I think the problem here is you need to get buy-in from everyone involved, which includes libraries@ (String), ghc (IsString is recognized in order to enable string overloading), ByteString, and potentially anyone who uses any of the above. That said, if you want to officially propose it you need to read up on how to properly propose such changes to libraries(a)haskell.org. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

1 0

containers: to be or not to be (strict, in this case)?
by Claus Reinke 05 Mar '09

05 Mar '09

[addressing libraries@ as the maintainer of containers] summary: could we please have equal support for all container operations, parameterised by element strictness? We are now starting to see issues with container strictness almost as often as we used to see the foldl/foldl' issue (the most recent example on cafe even used foldl' to accumulate an IntMap, unfortunately running into the non-strict nature of unionWith). As with foldl' itself, this is only partially a learning from experience issue: foldl' wasn't always available, and containers is rather inconsistent about supporting (element-)strict operations (Data.Map offers insertWith', Data.IntMap doesn't, neither offers strict unionWith; Data.Set is completely ambivalent about element strictness, depending on whether or not comparison is used). For the case of Maps, a partial workaround is known, namely to tie the availability of keys to evaluation of values. But this only works if key and value are supplied from the outside - which is not the case for the *With* family of functions (the supplied operation is applied to the old value, from within the Map, and the new value, from outside - there is no leverage to apply strictness), nor for map. Another workaround is to define your own strict insertWith', then to avoid the non-strict parts of the API: insertWith' op (k,v) m = maybe (IM.insert k v m) (\old->((IM.insert k) $! (v `op` old)) m) (IM.lookup k m) Apart from costing an extra lookup, that cannot be the intended way to use the API. If possible, I'd like to see both element-strict and element-non-strict containers supported, with otherwise the same APIs, and without a separate strict-containers package. The obvious disadvantage of code duplication (Data.Map has two definitions of insertWith) could perhaps be avoided, by parameterising the code over element strictness, as demonstrated here for Data.IntMap.insertWith: insertWithKey :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey = insertWithKeyS ($) insertWithKey' :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey' = insertWithKeyS ($!) type Strictness c a = (a -> c a) -> (a -> c a) -- constructor transformers insertWithKeyS :: Strictness IntMap a -> (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKeyS ($) f k x t = case t of Bin p m l r | nomatch k p m -> join k (Tip k $ x) p t | zero k m -> Bin p m (insertWithKeyS ($) f k x l) r | otherwise -> Bin p m l (insertWithKeyS ($) f k x r) Tip ky y | k==ky -> Tip k $ (f k x y) | otherwise -> join k (Tip k $ x) ky t Nil -> Tip k $ x The idea being to abstract over every application of the container constructors to the element type, then to supply either strict or non-strict application. Ultimately, one might prefer a type-constructor-based abstraction instead, to gain additional performance, but this should be at least as good as the current situation (perhaps with an INLINE on the parameterised versions), without the duplication. Btw, this variant is slightly stricter than Data.Map.insertWith', applying the strictness not only to the function passed in, but to all IntMap construction from the element type (seemed more consistent that way..). Claus

4 4

memory issues with cabal
by Paul Brown 04 Mar '09

04 Mar '09

Hi, All -- I'm having some issues getting cabal-install to upgrade itself to the current version (Cabal 1.6.0.2, cabal-install 0.6.2): > $ cabal install Cabal cabal-install > Resolving dependencies... > cabal: memory allocation failed (requested 2097152 bytes) I've tried various combinations of ghc options and RTS options passed in without success. The machine has plenty of horsepower for the task (8 cores, 20GB of RAM; Mac OS X 10.5.6, ghc 6.10.0) if I could convince cabal to use it... Any magic flags or tricks for this one? Thanks in advance. Paul Brown prb(a)mult.ifario.us http://mult.ifario.us http://www.linkedin.com/in/paulrbrown

2 2

Re: Failed to install leksah. (ghc-6.10.1 requires two versions of process)
by Jürgen Nicklisch-Franken 03 Mar '09

03 Mar '09

Hallo Andy, I'm sorry but this seems to be a cabal problem to me and I'm not shure how to fix this. In leksah.cabal the prerequisite is process >=1.0.1.0. Why and how ghc can require two different versions of the process library, well I don't know. I forward your question to the ghc library and leksah mailing list and hope we get a solution. Jürgen Am Dienstag, den 03.03.2009, 13:12 +0800 schrieb Andy Stewart: > Dear developers, > > I have install ghc-6.10.1 and gtk2hs-0.10 in Debian. > When i use cabal (1.6.0.2) install leksah, i got below error: > > Resolving dependencies... > cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.0 however > process-1.0.1.0 was excluded because ghc-6.10.1 requires process ==1.0.1.1 > > How to fix this? > > Thanks! > > -- Andy

3 2

Re-opening #2474
by Magnus Therning 03 Mar '09

03 Mar '09

I've again bumped into the issue I raised against old-locale: http://hackage.haskell.org/trac/ghc/ticket/2474 with a library submission in http://hackage.haskell.org/trac/ghc/ticket/2626 This resulted in no discussion at all on the list ( http://www.haskell.org/pipermail/libraries/2008-September/010709.html ) so would someone with privilege push the change into old-locale? I now I've not been following up properly on this, but hopefully that won't be held against me :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

1 0

randomIO causing stack overflow ?
by timtoorop＠quicknet.nl 02 Mar '09

02 Mar '09

Hi, I was just messing with randomIO for no particular reason, and it suddenly caused a stack overflow which would only go away after restarting ghci. Here's what I see in ghci 6.8.2 http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1642 mmorrow posted the same using ghci 6.10.1 which gave the same stack overflow Anyone got any idea what causes this funny behavior? - Tim

3 2