- Haskell-Cafe - Haskell.org

Haskell Meeting Munich
by Heinrich Hördegen 23 May '12

23 May '12

Dear all, our local hackathon in Munich on the 12th of May was a real success. Thanks to all those who joined! Look at the site for a picture: http://www.haskell-munich.de/dates Our next regular meeting is on Monday, the 28th of May at Cafe Puck at 19h30. This is a holiday in Germany. We hope that many of you will come! If you plan to do so, please click the button on the above mentioned site. Until then, I wish all of you a nice time, Heinrich -- hoerdegen(a)funktional.info www.funktional.info

1 0

HPC question
by David Turner 23 May '12

23 May '12

Dear Haskell Cafe, I've been playing around with the -fhpc option to GHC and have come across some things being highlighted yellow in the HTML markup for which I can't work out the right way to 'cover' them. A cut down program that shows what I'm talking about is at http://hpaste.org/68888 Looking at the output of hpc show, I see: 47 0 Main 15:6-15:9 ExpBox False 48 2 Main 15:6-15:9 ExpBox False 49 0 Main 15:6-15:9 ExpBox False 50 0 Main 15:6-15:9 ExpBox False 51 1 Main 22:13-22:14 TopLevelBox ["=="] 52 0 Main 22:13-22:14 TopLevelBox ["/="] 53 1 Main 22:17-22:20 TopLevelBox ["showsPrec"] 54 0 Main 22:17-22:20 TopLevelBox ["showList"] I.e. each of those bits whose highlighting I don't understand is made of some overlapping boxes, one of which is used. Now, if I fiddle in the .tix file by hand to fake a usage of (/=) by changing the 52nd entry from 0 to 1, the Eq instance isn't highlighted any more in the HTML output. More strangely, if I then remove the usage of (==) by changing the 51st entry from 1 to 0, the Eq instance still isn't highlighted. A similar effect happens with the Show instance. It seems to be highlighting based only on the last entry in the .tix file, where there are two or more identically-placed boxes. Is this right? I'd have expected that if I use (==) then the deriving (Eq) clause should be considered 'used'. Secondly, I can't work out what the four boxes in position 15:6-15:9 are supposed to be. If I use -ddump-simpl I can see many calls to 'tick' but there's no mention of numbers 47, 49 or 50. Perhaps they've been simplified away? I'm afraid I don't know what else to try dumping to get at the instrumented code before the simplifier's had a go at it. I'm using Haskell Platform 2011.2.0.1 (GHC 7.0.3) on Windows if that's relevant. Thanks in advance, David

2 3

Re: [Haskell-cafe] Please critique my code (a simple lexer)
by Lorenzo Bolla 23 May '12

23 May '12

> On Tue, May 22, 2012 at 4:13 PM, John Simon <zildjohn01(a)gmail.com> wrote: > >> data Lexer = Lexer String >> >> makeLexer :: String -> Lexer >> makeLexer fn = Lexer fn > > `makeLexer` is redundant. You can simply use `Lexer`. L.

1 0

cool tools
by Chris Dornan 23 May '12

23 May '12

I have been playing around with the latest cabal-install (0.14.0) and it is working really nicely. Having unpacked a cabal bundle you can now type 'cabal install' inside the root and it will work everything out as if you had asked to install directly from the repo -- very nice. I have also noticed that GHC is suggesting alternatives when it encounters missing identifiers. This gives a strong sense of helpfulness that I think accurately reflects the long and sustained (decades-long) effort that has gone into making the GHC diagnostics as useful as possible. The tools are so good because the developers have been paying attention to the gripes. But we should sometimes say thank you too... it is much appreciated. Chris

5 5

Can Haskell outperform C++?
by Janek S. 23 May '12

23 May '12

Hi, a couple of times I've encountered a statement that Haskell programs can have performance comparable to programs in C/C++. I've even read that thanks to functional nature of Haskell, compiler can reason and make guarantess about the code and use that knowledge to automatically parallelize the program without any explicit parallelizing commands in the code. I haven't seen any sort of evidence that would support such claims. Can anyone provide a code in Haskell that performs better in terms of execution speed than a well-written C/C++ program? Both Haskell and C programs should implement the same algorithm (merge sort in Haskell outperforming bubble sort in C doesn't count), though I guess that using Haskell-specific idioms and optimizations is of course allowed. Jan

27 55

Found quote: "One of the ineradicable illusions about C++ is that the compiler should be able to see through ...
by KC 23 May '12

23 May '12

all the abstractions and obfuscations an “advanced” C++ program contains. First and foremost, C++ should be seen as a language that enables complexity management. The features one has grown fond of in this concept, like operator overloading, object orientation, automatic construction/destruction, etc., are however mostly unsuitable for efficient low-level code." >From "Introduction to High Performance Computing for Scientists and Engineers" CRC Press, 2011. So if one avoids such C++ complexity management features and a Haskell compiler can see through most of the complexity management features of Haskell; they should be comparable. :) Casey -- -- Regards, KC

1 0

Please critique my code (a simple lexer)
by John Simon 23 May '12

23 May '12

Hi all, I've been teaching myself Haskell lately (I come from the C#/Python world). I wrote a simplistic lexer, and I was hoping I could get a code review or two. The code that follows is a stand-alone app that works under GHC. A few concerns of mine: - My `consume` function seems basic enough that it should be library code, but my searches turned up empty. Did I miss anything? - Is `case _ of x:xs -> x:xsr where xsr = something xs` a common idiom? It happened twice in my code, and it seems odd to split the first element away from the rest of the list as it's processed. - Is creating data structures with simple field names like `kind`, `offset`, etc a good practice? Since the names are global functions, I worry about namespace pollution, or stomping on functions defined elsewhere. Thanks in advance for anyone willing to take the time. -- code follows module Main where import qualified Data.Map as Map data Lexer = Lexer String makeLexer :: String -> Lexer makeLexer fn = Lexer fn data Loc = Loc {offset :: Int, line :: Int, column :: Int} locInc loc n = Loc (offset loc + n) (line loc) (column loc + n) locNL loc = Loc (offset loc + 1) (line loc + 1) 1 data TokenKind = Colon | RArrow1 | Def | Var | Identifier String | EOF deriving Show data Token = Token {lexer :: Lexer, loc :: Loc, kind :: TokenKind} idStart = ['a'..'z'] ++ ['A'..'Z'] ++ "!@$%^&*-_=+|<>/?" idNext = idStart ++ ['0'..'9'] ++ "'\"" namedTokens = Map.fromList [ ("def", Def), ("var", Var)] doLex :: Lexer -> String -> [Token] doLex lexer = doLex' lexer (Loc 0 1 1) doLex' lexer loc source = case source of [] -> [makeToken EOF] ' ':xs -> more (locInc loc 1) xs '\n':xs -> more (locNL loc) xs ':':xs -> makeToken Colon : more (locInc loc 1) xs '-':'>':xs -> makeToken RArrow1 : more (locInc loc 2) xs x:xs | x `elem` idStart -> makeToken kind : more (locInc loc $ length name) xsr where (namer, xsr) = consume idNext xs name = x:namer kind = maybe (Identifier name) id $ Map.lookup name namedTokens _ -> error "Invalid character in source" where makeToken = Token lexer loc more = doLex' lexer consume :: Eq a => [a] -> [a] -> ([a], [a]) consume want xs = case xs of x:xs | x `elem` want -> (x:xsr, rest) where (xsr, rest) = consume want xs _ -> ([], xs) main :: IO () main = do let toks = doLex (makeLexer "") "def x -> y" in putStrLn $ show $ map kind toks

4 3

Encoding issues with LDAP package
by Vincent Ambo 23 May '12

23 May '12

Hej, I'm using the LDAP package by John Goerzen to retrieve some information from an Active Directory database. Part of this information are the full names of my company's employees. Many of these names contain characters which aren't part of the standard ASCII set, for example ä å ü ê and so on. When I retrieve those names from the directory (the LDAP package returns them as Strings) the encoding breaks and I get results like "R\195\188diger" instead of "Rüdiger". The Active Directory server supports LDAP v2 and v3. I assume the OpenLDAP C API, which is the backend behind the LDAP package, automatically chooses v3 to connect if available (this is speculation, correct me if I'm wrong). Since LDAP v3 only speaks UTF8 and ASCII I also assume that the server returns UTF8. Is this a known problem in the LDAP package? Or is this related to the OpenLDAP C API? Or even something on the server side? Any information would be helpful! Best regards, Vincent

2 1

Heads up: importing the Cabal issue tracker to github next week
by Bryan O'Sullivan 23 May '12

23 May '12

I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, and you have filed bugs against Cabal in Trac, please brace yourself.

2 1

Haskell Day 2012 (in Japan)
by Kazu Yamamoto 23 May '12

23 May '12

Hello Cafe, This is just FYI. We Hasekell community in Japan will have an event called Haskell Day 2012 on 27th May to cerebrate the publication of the Japanese version of "Learn you". 180+ people have already registered: # This page is written in Japanese. http://partake.in/events/ab7f77b4-7541-47a4-867d-21a096ca883c P.S. The Japanese version of "Learn you" was on sale yesterday and already sold out in many bookstores. :-) --Kazu

1 0