- Haskell-Cafe - Haskell.org

ANNOUNCE: attempt
by Michael Snoyman 16 Nov '09

16 Nov '09

We'd like to announce the second release (version 0.0.1) of the attempt package, for handling of failures. This release has been made to work with the new control-monad-failure package[1] in an effort to standardize failure handling. Notable changes to this release: * The MonadAttempt class was fully redundant with MonadFailure, and has thus been removed. * WrapFailure class has been moved to control-monad-failure (with minor modifications). * Data.Attempt.Helper (safe versions of some functions) has been moved to safe-failure[2]. * Full support for the monadloc package[3] to get monadic stack traces. As usual, this release is available on hackage[4]. API stability cannot be guaranteed with this release as well, but we're getting much closer to hitting the mark. All the best, Michael Snoyman, Nicolas Pouillard 1. http://hackage.haskell.org/package/control-monad-failure 2. http://hackage.haskell.org/package/safe-failure 3. http://hackage.haskell.org/package/monadloc 4. http://hackage.haskell.org/package/attempt

1 1

ANNOUNCE: control-monad-failure and safe-failure
by Michael Snoyman 16 Nov '09

16 Nov '09

Folks, We are extremely happy to announce the control-monad-failure and safe-failure packages for error handling. control-monad-failure provides a basic notion of failure which does not commit to any concrete representation. It is just a version of the MonadError class without the annoying bits. > class MonadFailure e m where failure :: e -> m a Instances are provided for several concrete representations of failure handling: Maybe, Either, ErrorT, Control.Exception.Throw, and []. safe-failure is a fork of Neil Mitchell's Safe package providing MonadFailure versions of several partial functions in the Prelude, which instead of failing with a runtime error fail with Failure. > head :: MonadFailure HeadFailure m => [a] -> m a This is a joint release from the authors of the attempt and the control-monad-exception packages, and accompanying releases of those packages have been made making them adopt the MonadFailure interface. We have also created a wiki page explaining our reasons for following this path in: http://www.haskellwiki.org/Failure Thanks, Jose Iborra, Nicolas Pouillard and Michael Snoyman

3 2

Could someone teach me why we use Data.Monoid?
by Magicloud Magiclouds 16 Nov '09

16 Nov '09

Hi, I have looked the concept of monoid and something related, but still, I do not know why we use it? -- 竹密岂妨流水过山高哪阻野云飞

18 29

Coercing numeric and string constants
by Mark Lentczner 16 Nov '09

16 Nov '09

I'm looking for a good way to handle a library interface that accepts both strings and numbers in particular argument positions: Start with the following definitions. I've defined ResourceTree as a class here since the details don't matter. > data Segment = Key String | Index Int > deriving (Eq, Show) > > type Path = [Segment] > > class ResourceTree a where > lookupPath :: Path -> a -> Maybe String What I'm after is to make the following code, representative of intended client usage to work: > examples :: (ResourceTree a) => a -> [Maybe String] > examples r = [ > r `at` "status", > r `at` 7, > r `at` "part" ./ "sku", > r `at` "items" ./ 2, > r `at` 7 ./ "name", > r `at` 7 ./ 9 > ] The first way I thought to do this was with type classes: > class Segmentable a where { toSegment :: a -> Segment } > instance Segmentable Segment where { toSegment = id } > instance Segmentable String where { toSegment = Key } > instance Segmentable Int where { toSegment = Index } > > class Pathable a where { toPath :: a -> Path } > instance Pathable Path where { toPath = id } > instance Pathable String where { toPath s = [ Key s ] } > instance Pathable Int where { toPath i = [ Index i ] } > > (./) :: (Segmentable a, Pathable b) => a -> b -> Path > a ./ b = toSegment a : toPath b > infixr 4 ./ > > at :: (ResourceTree a, Pathable b) => a -> b -> Maybe String > a `at` b = lookupPath (toPath b) a > infix 2 `at` This works great for all uses in the client code where the type of the numeric arguments are known or otherwise forced to be Int. However, when used with numeric constants (as in the function example above), it fails due to the way that numeric constants are defined in Haskell. For example, the constant 9 in example results in this error: Ambiguous type variable `t4' in the constraints: `Pathable t4' arising from a use of `./' at Test.hs:48:15-20 `Num t4' arising from the literal `9' at Test.hs:48:20 Probable fix: add a type signature that fixes these type variable(s) I suppose that even though there is only one type that is both an instance of Num and of Pathable (Int), that can't be deduced with certainty. In the client code, one could fix this by typing the constants thus: > r `at` (7::Int) ./ (9::Int) But to me that makes a hash out of the concise syntax I was trying to achieve. Also, this code requires both FlexibleInstances and TypeSynonymInstances pragmas (though the later requirement could be worked around.), though I'm lead to understand that those are common enough. I think also that, these are only needed in the library, not the client code. The other way I thought to do this is by making Path and Segment instances of Num and IsString: > instance Num Segment where { fromInteger = Index . fromInteger } > instance IsString Segment where { fromString = Key . fromString } > instance Num Path where { fromInteger i = [ Index $ fromInteger i ] } > instance IsString Path where { fromString s = [ Key $ fromString s ] } > > (./) :: Segment -> Path -> Path > a ./ b = a : b > infixr 4 ./ > > at :: (ResourceTree a) => a -> Path -> Maybe String > a `at` b = lookupPath b a > infix 2 `at` This works but has two downsides: 1) Segment and Path are poor instances of Num, eliciting errors for missing methods and resulting in run-time errors should any client code accidentally use them as such. 2) It requires the OverloadedStrings pragma in every client module. Any comments on these two approaches would be appreciated, How to improve them? Which is the lesser of two evils? On the other hand, I realize that many may object that intended interface isn't very Haskell like. The data object I need to represent (ResourceTree) comes from external input and really does have the strange "paths of strings or integers" construction, I can't change that. And it is expected that much client code will use constant paths to access and manipulate various parts of such objects, hence the desire for a concise operator set that works with constants. Given that there are actually several operations on ResourceTree involving paths (where the operation requires the whole Path as a single value), any thoughts on a more Haskell like construction? Thanks, - MtnViewMark Mark Lentczner http://www.ozonehouse.com/mark/ mark(a)glyphic.com

2 1

[Haskell-cafe] unboxed arrays restricted to simple types (Int, Float, ..)
by Tillmann Vogt 16 Nov '09

16 Nov '09

Hi, I tried to use unboxed arrays for generating an antialiased texture. To make it easier to understand, here is the stripped down code that produces an error: >import Control.Monad.ST >import Data.Array.ST >import Data.Array.Unboxed >import Data.Word >type BitMask = UArray Int Word16 -- for determining the grey value of a pixel >type Pixels = (Int, Int, T) >data T = N | B BitMask -- this does not work >-- type T = Int -- this works if int the next line N is replaced by ..lets say 0 >f = newArray (0,10) N :: (ST s (STUArray s Int T)) http://hackage.haskell.org/packages/archive/array/0.2.0.0/doc/html/Data-Arr… shows that mutable/unboxed arrays only allow simple types: i.e. MArray (STUArray s) Int32 (ST s) Isn't this ugly? Imagine this would be the case in C: struct stupidArrayElement{ int a; int b; // not allowed! } stupidArrayElement s[10]; Wouldn't it be nice to have something like: MArray (STUArray s) e (ST s) with e being a non-recursive data type (like data T = N | B Bitmask). My understanding of Haskell isn't deep enough to know if I have overlooked something or if the problem is solvable without a language extension. With a language extension I guess that it is not hard to find out if an abstract data type is non-recursive. Then this type should be serializable automatically. What do you think?

6 5

ANNOUNCE: New Industrial Haskell Group membership options
by Duncan Coutts 16 Nov '09

16 Nov '09

The Industrial Haskell Group (IHG) is an organisation to support the needs of commercial users of the Haskell programming language. The second round of the IHG's collaborative development scheme will be running for 6 months from January. We are now inviting additional companies to take part. This scheme is ideal for companies that make significant use of Haskell and wish to fund specific projects. Additionally, there are new associate and academic membership options. These enable companies and academic groups to support the general health of the Haskell development platform, but with a lower financial commitment. For more details on all of the above, please see http://industry.haskell.org/ If your company or group is interested in joining then please e-mail info(a)industry.haskell.org -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

who wrote the Relational_Algebra page
by Günther Schmidt 16 Nov '09

16 Nov '09

on the Haskell wiki? http://www.haskell.org/haskellwiki/Relational_algebra Günther

3 4

Trouble installing HDBC 2.1.1 with ghc 6.10.4
by Colin Paul Adams 16 Nov '09

16 Nov '09

I'm seeing messages such as: Database/HDBC/SqlValue.hs:610:32: No instance for (Typeable Day) .... Is this connected with the in-and-out status of the time library in the GHC 6.10.x series? Is there a work-around? -- Colin Adams Preston Lancashire

2 1

haskell-src-exts Question
by Dominic Steinitz 16 Nov '09

16 Nov '09

I've been generating Haskell using haskell-src-exts but the prettyprinter isn't producing what I would expect. I would expect parse . prettyPrint == id i.e. the AST should be unchanged if you prettyprint it then parse it. Here's an example generated expression: App (App (Var (UnQual (Ident "pay"))) (Var (UnQual (Ident "tPD")))) (App (Var (UnQual (Ident "a"))) (InfixApp (App (Var (UnQual (Ident "length"))) (Var (UnQual (Ident "tOD")))) (QVarOp (UnQual (Symbol "+"))) (Lit (Int (-1))))) Here's what prettyPrint produces: pay tPD a length tOD + -1 Parsing it gives this (i.e. not the expression I first thought of): InfixApp (App (App (App (App (Var (UnQual (Ident "pay"))) (Var (UnQual (Ident "tPD")))) (Var (UnQual (Ident "a")))) (Var (UnQual (Ident "length")))) (Var (UnQual (Ident "tOD")))) (QVarOp (UnQual (Symbol "+"))) (NegApp (Lit (Int 1))) I would have expected the prettyprinter to produce this: pay tPD (a (length tOD + -1)) Do I have to write my own prettyprinter? Do I have to put in explicit parentheses? The latter seems unsatisfactory as my generated AST is unambiguous and bracketing ought to be part of the prettyprinter. The former would be quite a lot of code as there are many cases to consider. Dominic.

6 11

poor perfomance of indexU in uvector package
by Alexey Khudyakov 16 Nov '09

16 Nov '09

Hello This post meant to be literate haskell. I found that perfomace of indexU is very poor and it is not fast O(1) operation which is very surprising. Here is some benchmarcking I've done. Everything compiled with -O2 Code below converts square 2D array to list of 1D arrays. Summation of array contents is done in force evaluation > import Control.Monad > import Control.Monad.ST > import Data.Array.Vector > import System > > arr :: Int -> UArr Double > arr n = toU $ map fromIntegral [1 .. n*n] > This is fastest function. It slice arrays along another direction and used mainly as upper bound of speed > sliceY :: Int -> UArr Double -> [UArr Double] > sliceY n a = map (\i -> sliceU a (i*n) n) [0 .. n-1] > Naive implementation using lists and index lookup. 2.15 second for 200*200 array > sliceXlist :: Int -> UArr Double -> [UArr Double] > sliceXlist n a = map mkSlice [0 .. n-1] > where > mkSlice x = toU $ map (\y -> indexU a (x + y*n)) [0 .. n-1] Similar implementation in ST monad and it uses indexU too. 2.14 seconds for 200*200 array > sliceXst :: Int -> UArr Double -> [UArr Double] > sliceXst n a = map mkSlice [0 .. n-1] > where > mkSlice x = runST $ do arr <- newMU n > forM_ [0 .. n-1] $ \y -> writeMU arr y (indexU a (y*n + x)) > unsafeFreezeAllMU arr This implementation avoids use of indexU by copying entire 2D array into mutable array and using it for lookup. Surprisingly it outperform previsious implementations for sufficiently big n 1.19 seconds for 200*200 array > sliceXcopy :: Int -> UArr Double -> [UArr Double] > sliceXcopy n a = map mkSlice [0 .. n-1] > where > mkSlice x = runST $ do arr <- newMU n > cp <- newMU (n*n) > copyMU cp 0 a > forM_ [0 .. n-1] $ \y -> writeMU arr y =<< readMU cp (y*n + x) > unsafeFreezeAllMU arr This is another implementation with lists which convert whole array to list and picks appropriate element it. It is fastest implementation so far. 0.039 seconds for 200*200 array > sliceXlistfast :: Int -> UArr Double -> [UArr Double] > sliceXlistfast n a = map mkSlice [0 .. n-1] > where > takeEvery n [] = [] > takeEvery n (x:xs) = x : takeEvery n (drop (n-1) xs) > mkSlice x = toU $ takeEvery n . drop x $ fromU a > > > ---------------------------------------------------------------- > main :: IO () > main = do > [str,a] <- getArgs > let n = read str > case a of > "y" -> print $ sum $ map sumU (sliceY n (arr n)) > "list" -> print $ sum $ map sumU (sliceXlist n (arr n)) > "lf" -> print $ sum $ map sumU (sliceXlistfast n (arr n)) > "st" -> print $ sum $ map sumU (sliceXst n (arr n)) > "copy" -> print $ sum $ map sumU (sliceXcopy n (arr n))

6 8