July 2009 - Haskell-Cafe

Haskell used for data analysis - OLAP?
by Günther Schmidt 12 Jul '09

12 Jul '09

Hi, I've developed this commercial app in Haskell with all of the business logic coded in SQL with the help of haskelldb. Some of the intermediate results (of queries) I had to manifest in extra tables because the initial query was expensive, the intermediate result would be the "source" data of other queries and queries can't themselves be indexed for further efficient querying. Since the amount of data could become rather large, in-memory processing wasn't an option and I thus chose SQL (Sqlite). The solution works, but still I'm not quite happy about it, since I consider the tables that hold intermediate results fixes. I understand that the financial industry employs Haskell to analyse large data set under complex schemes. I wonder what techniques are employed for that, do they use Haskell to create some sort of OLAPish tools? Do they use Haskell to run complex queries against SQL data warehouses? Günther

2 1

Text.JSON, Speed and Bytestrings
by Max Cantor 11 Jul '09

11 Jul '09

Hi Cafe, I am using the Text.JSON library to [un]marshall messages passed over the network and was wondering if the speed would be significantly improved by either changing the code or adding a module to implement the same functionality using Bytestrings instead of classical strings? If the consensus is that it would be worth it, I'll look into adding that code.. Thanks, Max

2 1

About the return type
by xu zhang 11 Jul '09

11 Jul '09

I have trouble in returning a list of Figures. I want return a type of m (Maybe [Figure IO]), but the type of dv_findFigure is :: a -> Point -> s (Maybe (Figure s)). How can change the code below to get a s (Maybe [Figure s])? Thank you in advance! dv_findFigure :: a -> Point -> s (Maybe (Figures)) fig_contains :: fig -> Point -> m Bool anc :: Point do fs <- dv_getSelFigs dv fs' <- filterM (`fig_contains` anc) fs f <- case fs' of [] -> dv_findFigure dv anc fig : _ -> return $ Just fig case f of Just f' -> tool_dragtrack self f' Nothing -> dv_clearSel dv >> tool_areatrack self Couldn't match expected type `Figure m' against inferred type `[Figure IO]' Expected type: m (Maybe (Figure m)) Inferred type: m (Maybe [Figure IO]) In the expression: return $ Just fs In a case alternative: fig : _ -> return $ Just fs

2 1

following up on space leak
by Uwe Hollerbach 11 Jul '09

11 Jul '09

Good evening, all, following up on my question regarding space leaks, I seem to have stumbled across something very promising. I said I was using this tiny function "lastOrNil" to get the last value in a list, or the empty (scheme) list if the haskell list was empty. The uses of it were all of the form lastOrNil (mapM <something> <some list>) so I wrote a different function mapML to do this directly: > mapML fn lst = mapMLA (List []) fn lst > where mapMLA r _ [] = return r > mapMLA ro fn (x:xs) = > do rn <- fn x > mapMLA rn fn xs This isn't an accumulator, it's a replacer (or, if you like, the "accumulation" is "drop the old one on the floor"), it starts out with the scheme empty list that I want as the default, and it never even builds the list which it'll just dump an instant later. Shazam! Memory usage dropped by roughly an order of magnitude in my little Collatz benchmark, and incidentally runtime improved by 25% or so as well. The horror! :-) Having tasted blood, I will of course be continuing to benchmark... but not tonight. Uwe

5 8

get cabal info for self?
by Keith Sheppard 11 Jul '09

11 Jul '09

Is there a way for a cabalized program to get its own info. I'm specifically interested in version info. Thanks Keith -- keithsheppard.name

2 2

Flipping *->*->* kinds, or monadic finally-tagless madness
by Kim-Ee Yeoh 11 Jul '09

11 Jul '09

I'm trying to write HOAS Show instances for the finally-tagless type-classes using actual State monads. The original code: http://okmij.org/ftp/Computation/FLOLAC/EvalTaglessF.hs Two type variables are needed: one to vary over the Symantics class (but only as a phantom type) and another to vary over the Monad class. Hence, the use of 2-variable type constructors. > type VarCount = int > newtype Y b a = Y {unY :: VarCount -> (b, VarCount)} Not knowing of a type-level 'flip', I resort to newtype isomorphisms: > newtype Z a b = Z {unZ :: Y b a} > instance Monad (Z a) where > return x = Z $ Y $ \c -> (x,c) > (Z (Y m)) >>= f = Z $ Y $ \c0 -> let (x,c1) = m c0 in (unY . unZ) (f > x) c1 -- Pace, too-strict puritans > instance MonadState String (Z a) where > get = Z $ Y $ \c -> (show c, c) > put x = Z $ Y $ \_ -> ((), read x) So far so good. Now for the Symantics instances (abridged). > class Symantics repr where > int :: Int -> repr Int -- int literal > add :: repr Int -> repr Int -> repr Int > lam :: (repr a -> repr b) -> repr (a->b) > instance Symantics (Y String) where > int = unZ . return . show > add x y = unZ $ do > sx <- Z x > sy <- Z y > return $ "(" ++ sx ++ " + " ++ sy ++ ")" The add function illustrates the kind of do-sugaring we know and love that I want to use for Symantics. > lam f = unZ $ do > show_c0 <- get > let > vname = "v" ++ show_c0 > c0 = read show_c0 :: VarCount > c1 = succ c0 > fz :: Z a String -> Z b String > fz = Z . f . unZ > put (show c1) > s <- (fz . return) vname > return $ "(\\" ++ vname ++ " -> " ++ s ++ ")" Now with lam, I get this cryptic error message (under 6.8.2): Occurs check: cannot construct the infinite type: b = a -> b When trying to generalise the type inferred for `lam' Signature type: forall a1 b1. (Y String a1 -> Y String b1) -> Y String (a1 -> b1) Type to generalise: forall a1 b1. (Y String a1 -> Y String b1) -> Y String (a1 -> b1) In the instance declaration for `Symantics (Y String)' Both the two types in the error message are identical, which suggests no generalization is needed. I'm puzzled why ghc sees an infinite type. Any ideas on how to proceed? -- View this message in context: http://www.nabble.com/Flipping-*-%3E*-%3E*-kinds%2C-or-monadic-finally-tagl… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

4 8

[Haskell Cafe] Parsec: buildExpressionParser and parens typecheck problem
by Paul Sujkov 11 Jul '09

11 Jul '09

Hi haskellers, I'm trying to use buildExpressionParser parser generator from ParsecExpr module of Parsec ( http://legacy.cs.uu.nl/daan/download/parsec/parsec.html#ParsecExpr) It works well, except for the "parens" token parser ( http://legacy.cs.uu.nl/daan/download/parsec/parsec.html#parens) This code (sample from Expressions part of the manual) typechecks fine: expr :: Parser Integer expr = buildExpressionParser table factor <?> "expression" table = [[op "*" (*) AssocLeft, op "/" div AssocLeft] ,[op "+" (+) AssocLeft, op "-" (-) AssocLeft] ] where op s f assoc = Infix (do{ string s; return f}) assoc factor = do{ char '(' ; x <- expr ; char ')' ; return x } <|> number <?> "simple expression" but if I try to use parens: factor = parens expr <|> number <?> "simple expression" it fails to typecheck: Couldn't match expected type `GenTokenParser s u m' against inferred type `Parser Integer' In the first argument of `parens', namely `expr' In the first argument of `(<|>)', namely `parens expr' In the first argument of `(<?>)', namely `parens expr <|> number' Failed, modules loaded: none. the type of expr infers to GenParser Char () Integer, and the expected type for the parens is GenTokenParser s u m (however, manual introduces it with the type CharParser st a expected) It seems pretty weird for me, as there are numerous examples of using parens with the buildExpressionParser (e.g. http://blog.moertel.com/articles/2005/08/27/power-parsing-with-haskell-and-…) and nobody comments such an error. I know I'm missing something very simple here, maybe someone could help me with it? Thanks in advace I'm using GHC 6.10.1 and Parsec 3.0.0 -- Regards, Paul Sujkov

2 1

Laziness enhances composability: an example
by Cristiano Paris 10 Jul '09

10 Jul '09

Hi, I'm wondering what a good example of why laziness enhances composability would be. I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell. Thanks, Cristiano

8 9

first project. code reviews?
by Jared Jennings 10 Jul '09

10 Jul '09

I've written a parser for OFX 1.x (these are the files you can download from most banks detailing recent account activity). I'm not sure I've written it well. This is my first serious thing in Haskell. (Kudos to the writers of the guide for how to make a new Hackage project! It's brilliant.) http://patch-tag.com/r/ofx1/pullrepo

2 1

Leaner Haskell.org frontpage
by Jeff Wheeler 10 Jul '09

10 Jul '09

On Thu, Jul 9, 2009 at 6:12 PM, Derek Elkins<derek.a.elkins(a)gmail.com> wrote: > I'm not a newbie and I don't use the front page terribly often, but I > do like most of the links that are on it. The Ruby page is certainly > prettier, but the layout of the Haskell page is fine in my opinion; > the difference is mainly eye-candy. On another topic, I know people > have expressed that they have liked the fact that the entire Haskell > site is a wiki; this expressing openness and community involvement. > I personally don't find the Haskell front page too cluttered and I > think most of issue in that vein could be resolved by simply making > sure the most important/newbie-oriented links are "above the fold" and > appropriately emphasized/categorized as is partially done already. I strongly feel that the homepage should be made more newbie friendly, and I think the Ruby page has done this well, disregarding the news section. I suspect most people who like the Ruby page see the "Ruby is..." section as especially effective at introducing the language, and the random snippet is a simple way to show off a bit of code before they dive into a tutorial. Furthermore, the "Download" link is useful, but since GHC can be complicated (and varies by platform), we probably want to include pretty well thought-out instructions behind the link if we include a similar feature. I also quite like the "Participate" box on the Ruby page, which is very inviting. Regarding the current Haskell homepage, I feel the events are given far too high a place on the homepage. Almost no newbies will be interested in these, and most experienced users will know of the events via the mailing lists. The headlines below that deserve significantly more attention, and perhaps should be updated with greater frequency (and dated, and have RSS). The updated package list is fine, I think. The navigation is a bit tricky, in my opinion. To a beginner (that doesn't know what GHC is), the two download links may be confusing, although I suspect most would correctly assume that "Download Haskell" was correct option. The "Find A Library" is a good link, but the Search that follows it is awkward. There are three large search choices for beginners: 1) the search at the top, which confusingly has two submit buttons (with ambiguous differences to a beginner); 2) the Search link near the top of the navigation (which links to an almost empty page that might as well be included at the link's location); and 3) the Search link underneath the About header, which doesn't seem to belong at all. Jeff Wheeler (Sorry, sent this to just Derek at first.)

3 2