July 2013 - Haskell-Cafe

Problem with pipes interpretation of Lazy MapM program.
by Lyndon Maydwell 11 Jul '13

11 Jul '13

Hi café. I've come up with a little version of 'uniq' that should take into account md5 sums of the file changes... In essence, this: main :: IO () main = getContents >>= mapM check . lines -- PROBLEM!!!! >>= mapM_ (putStrLn . (" --> " ++ )) . strip check :: String -> IO (String, ABCD) check s = (s,) . md5 . Str <$> readFile s strip :: (Ord a, Eq b) => [(a,b)] -> [a] strip = concat . uncurry (zipWith look) . (id &&& maps) look :: (Ord a, Eq b) => (a,b) -> M.Map a b -> [a] look (k,v) m | M.lookup k m == Just v = [] | otherwise = [k] maps :: Ord a => [(a,b)] -> [M.Map a b] maps = scanl (flip (uncurry M.insert)) M.empty Unfortunately mapM isn't lazy, so this doesn't work. I thought this would be a good opportunity to try out the Pipes library for a simple real-world task, but I've come up against some issues with using 'zip' and 'scan' like functions when translating the code. This is what I've got so far, but I'm not sure how to proceed: main :: IO () main = runProxy $ stdinS >-> pipe >-> stdoutD pipe :: () -> ProxyFast () String () String IO () pipe = mapMD check >-> mapScan -- zip, check, output go here >-> mapD ((" --> " ++) . show) mapScan :: () -> ProxyFast () (String, ABCD) () (M.Map String ABCD) IO b mapScan = scanlp (uncurry M.insert) (M.empty) check :: String -> IO (String, ABCD) check s = (s,) . md5 . Str <$> readFile s -- Utils scanlp :: (Monad (p () t a b1 m), Monad m, Functor (p () t a b1 m), Proxy p) => (t -> b1 -> b1) -> b1 -> () -> p () t a b1 m b scanlp f a b = do void $ respond a v <- request () scanlp f (f v a) b There doesn't seem to be any easy zipLike functions, and having to write my own scan function seems odd. Can someone point me in the right direction for this? Thanks! - Lyndon

1 0

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]
by oleg＠okmij.org 11 Jul '13

11 Jul '13

Alberto G. Corona wrote: > I think that a non-non recursive let could be not compatible with the pure > nature of Haskell. I have seen this sentiment before. It is quite a mis-understanding. In fact, the opposite is true. One may say that Haskell is not quite pure _because_ it has recursive let. Let's take pure the simply-typed lambda-calculus, or System F, or System Fomega. Or the Calculus of Inductive Constructions. These calculi are pure in the sense that the result of evaluation of each expression does not depend on the evaluation strategy. One can use call-by-name, call-by-need, call-by-value, pick the next redex at random or some other evaluation strategy -- and the result will be just the same. Although the simply-typed lambda-calculus is quite limited in its expressiveness, already System F is quite powerful (e.g., allowing for the list library), to say nothing of CIC. In all these systems, the non-recursive let let x = e1 in e2 is merely the syntactic sugar for (\x. e2) e1 OTH, the recursive let is not expressible. (Incidentally, although System F and above express self-application (\x.x x), a fix-point combinator is not typeable.) Adding the recursive let introduces general recursion and hence the dependence on the evaluation strategy. There are a few people who say non-termination is an effect. The language with non-termination is no longer pure.

1 0

Non-recursive let [Was: GHC bug? Let with guards loops]
by oleg＠okmij.org 11 Jul '13

11 Jul '13

Andreas wrote: > The greater evil is that Haskell does not have a non-recursive let. > This is source of many non-termination bugs, including this one here. > let should be non-recursive by default, and for recursion we could have > the good old "let rec". Hear, hear! In OCaml, I can (and often do) write let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. BASIC comes to mind. I tried to lobby Simon Peyton-Jones for the non-recursive let a couple of years ago. He said, write a proposal. It's still being written... Perhaps you might want to write it now. In the meanwhile, there is a very ugly workaround: test = runIdentity $ do (x,s) <- return $ foo 1 [] (y,s) <- return $ bar x s (z,s) <- return $ baz x y s return (z,s) After all, bind is non-recursive let.

7 13

Non-recursive let [Was: GHC bug? Let with guards loops]
by oleg＠okmij.org 10 Jul '13

10 Jul '13

> If you would like to write > > let (x,s) = foo 1 [] in > let (y,s) = bar x s in > let (z,s) = baz x y s in > > instead, use a state monad. Incidentally I did write almost exactly this code once. Ironically, it was meant as a lead-on to the State monad. But there have been other cases where State monad was better avoided. For instance, functions like foo and bar are already written and they are not in the state monad. For example, foo may take a non-empty Set and return the minimal element and the set without the minimal element. There are several such handy functions in Data.Set and Data.Map. Injecting such functions into a Set monad for the sake of three lines seems overkill. Also, in the code above s's don't have to have the same type. I particularly like repeated lets when I am writing the code to apply transformations to it. Being explicit with state passing improves the confidence. It is simpler to reason with the pure code.

3 2

Is the following implemented by a sparse matrix representation? type Graph n w = Array (n, n) (Maybe w)
by KC 10 Jul '13

10 Jul '13

type Graph n w = Array (n,n) (Maybe w) -- -- Regards, KC

3 3

Re: [Haskell-cafe] Parsec error message not making any sense
by Fredrik Karlsson 10 Jul '13

10 Jul '13

Hi, Sorry, that was a careless extraction of code - I should have made sure that it was complete. Please, have a look again. When downloading and running the gist ( https://gist.github.com/dargosch/5955045) , I still get the error: Main> let testFile = "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid" *Main> parseFromFile textgridfile testFile Left "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid" (line 35, column 5): unexpected "t" expecting "intervals [" on the attached testfile. The "tier" parser works once, but then I get an error that I cant understand, given the input. How come the parser finds the "unexpected "t"" when the expected thing is what is in the input at that point? Thankful for any help I can get on this. On Tue, Jul 9, 2013 at 10:22 PM, Fredrik Karlsson <dargosch(a)gmail.com>wrote: > Hi, > > Sorry, that was a careless extraction of code - I should have made sure > that it was complete. > Please, have a look again. When downloading and running the gist, I still > get the error: > > Main> let testFile = > "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid" > *Main> parseFromFile textgridfile testFile > Left > "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid" > (line 35, column 5): > unexpected "t" > expecting "intervals [" > > on the attached testfile. The "tier" parser works once, but then I get an > error that I cant understand, given the input. > How come the parser finds the "unexpected "t"" when the expected thing is > what is in the input at that point? > > Thankful for any help I can get on this. > > > /Fredrik > > > On Tue, Jul 9, 2013 at 9:37 AM, Roman Cheplyaka <roma(a)ro-che.info> wrote: > >> Please check your code. >> >> I had two problems with it: mixed tabs and spaces, and undefined >> 'quotedChar'. After defining quotedChar = anyChar, I get a different >> error message from yours: >> >> *Main> parseFromFile textgridfile "testdata.TextGrid" >> Left "testdata.TextGrid" (line 137, column 1): >> unexpected end of input >> expecting quote at end of cell >> >> Roman >> >> * Fredrik Karlsson <dargosch(a)gmail.com> [2013-07-09 08:07:24+0200] >> > Hi Roman, >> > >> > I'm using parsec-3.1.3 >> > >> > I put the code in a gist here - sorry about that. >> > >> > https://gist.github.com/dargosch/5955045 >> > >> > Fredrik >> > >> > >> > >> > >> > On Tue, Jul 9, 2013 at 12:08 AM, Roman Cheplyaka <roma(a)ro-che.info> >> wrote: >> > >> > > Hi Fredrik, >> > > >> > > First, do you use the latest parsec version (3.1.3)? If not, can you >> try >> > > the same with 3.1.3? >> > > >> > > Second, please upload your code to hpaste.org or a similar service >> and >> > > give us the link. It's not much fun to extract code from an html >> email. >> > > >> > > Roman >> > > >> > > * Fredrik Karlsson <dargosch(a)gmail.com> [2013-07-08 23:54:17+0200] >> > > > Dear list, >> > > > >> > > > I have a Parsec parser that fails and gives the following error >> message: >> > > > >> > > > *Main> parseFromFile textgridfile testFile >> > > > Left >> > > > >> > > >> "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid" >> > > > (line 35, column 5): >> > > > unexpected "t" >> > > > expecting "intervals [" >> > > > >> > > > Now, this is perfectly understandable, but line 35, col 5 in the >> file >> > > being >> > > > parsed looks like the supplies image - there is no 't' there. >> > > > >> > > > Any ideas on what is going on? >> > > > >> > > > The parser I am using is: >> > > > >> > > > data VariableLine = VariableLine String String deriving Show >> > > > data TierType = IntervalTier | PointTier deriving Show >> > > > >> > > > data Tier = Tier String deriving Show >> > > > data LabelFile = LabelFile Double Double deriving Show >> > > > >> > > > data Label = Label String TierType Double Double String deriving >> Show >> > > > >> > > > >> > > > haskelldef = makeTokenParser haskellDef >> > > > >> > > > >> > > > textgridfile :: Parser (LabelFile, [[Label]]) >> > > > textgridfile = do >> > > > h <- header >> > > > ll <- many1 tier >> > > > return $ (h,ll) >> > > > >> > > > header :: Parser LabelFile >> > > > header = do >> > > > string headTS1 >> > > > start <- try (float haskelldef) >> > > > <|> (fmap fromInteger $ integer haskelldef ) >> > > > string "xmax = " >> > > > end <- try (float haskelldef) >> > > > <|> (fmap fromInteger $ integer haskelldef ) >> > > > string "tiers? <exists> \n" >> > > > string "size = " >> > > > integer haskelldef >> > > > string "item []:" >> > > > whiteSpace haskelldef >> > > > return $ LabelFile start end >> > > > >> > > > tier :: Parser [Label] >> > > > tier = do >> > > > whiteSpace haskelldef >> > > > string "item [" >> > > > integer haskelldef >> > > > string "]:" >> > > > whiteSpace haskelldef >> > > > try (string "class = \"IntervalTier\"") >> > > > <|> string "class = \"TextTier\"" >> > > > whiteSpace haskelldef >> > > > string "name = " >> > > > char '"' >> > > > name <- many quotedChar >> > > > char '"' <?> "quote at end of cell" >> > > > whiteSpace haskelldef >> > > > string "xmin = " >> > > > try (float haskelldef) <|> (fmap fromInteger $ integer haskelldef ) >> > > > whiteSpace haskelldef >> > > > string "xmax = " >> > > > try (float haskelldef) <|> (fmap fromInteger $ integer haskelldef ) >> > > > string "intervals: size = " <|> string "points: size = " >> > > > integer haskelldef >> > > > whiteSpace haskelldef >> > > > labelList <- many1 (interval name) >> > > > return $ labelList >> > > > interval :: String -> Parser Label >> > > > interval tierName = do >> > > > whiteSpace haskelldef >> > > > string "intervals [" >> > > > integer haskelldef >> > > > string "]:" >> > > > whiteSpace haskelldef >> > > > string "xmin = " >> > > > start <- try (float haskelldef) >> > > > <|> (fmap fromInteger $ integer haskelldef ) >> > > > whiteSpace haskelldef >> > > > string "xmax = " >> > > > end <- try (float haskelldef) >> > > > <|> (fmap fromInteger $ integer haskelldef ) >> > > > whiteSpace haskelldef >> > > > string "text = " >> > > > char '"' >> > > > text <- many quotedChar >> > > > char '"' <?> "quote at end of cell" >> > > > return $ Label tierName IntervalTier start end text >> > > > >> > > > which fails on the attached input file. >> > > > >> > > > I can't see how 't' is found?? What am I doing wrong? >> > > > >> > > > /Fredrik >> > > > >> > > > >> > > > >> > > > -- >> > > > "Life is like a trumpet - if you don't put anything into it, you >> don't >> > > get >> > > > anything out of it." >> > > >> > > >> > > >> > > > _______________________________________________ >> > > > Haskell-Cafe mailing list >> > > > Haskell-Cafe(a)haskell.org >> > > > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > >> > > >> > >> > >> > -- >> > "Life is like a trumpet - if you don't put anything into it, you don't >> get >> > anything out of it." >> >> >> > > > -- > "Life is like a trumpet - if you don't put anything into it, you don't get > anything out of it." > -- "Life is like a trumpet - if you don't put anything into it, you don't get anything out of it."

2 1

Engineering position at Vector Fabrics
by Stefan Holdermans 10 Jul '13

10 Jul '13

Vector Fabrics has another position open for a functional programmer. See below and http://www.vectorfabrics.com/company/career/functional_programmer for details. This time, we particularly welcome applications from experienced developers, the position providing a fair share of opportunities for growing into the rôle of an architect. Interested? Please contact us at jobs <AT> vectorfabrics.com. Cheers, Stefan ---------------------------------------------------------------------- Vector Fabrics is growing the team: we are looking for a top-notch programmer to extend our program-analysis and parallelization products. You design and implement algorithms to assist programmers in creating parallel designs from sequential C or C++ programs. You work with our international team of world-class computer scientists and experts in the Haskell / OCaml functional programming languages. Your work is at the forefront of technology, giving you the opportunity to publish your work in major conferences and directly cooperate with processor design companies and domain-specific application vendors. As we are a startup company, you will quickly have a major impact on our products and get to know all aspects of product creation. You will be part of a strongly committed development team and contribute to our agile development process and automated test suites. Interested? Send your CV, GitHub account or other proof of what you can do to jobs(a)vectorfabrics.com. RESPONSIBILITIES * Design and implement software optimization (e.g. parallelization) algorithms for CPUs and GPUs; * Thoroughly test your code, create automated test suites; * Contribute to our agile development planning and process; * Analyze complex customer applications for optimization opportunities and translate this to new analysis algorithms. PROFILE * Your friends and colleagues describe you as a superb programmer; your programming ability is way above average; * Demonstrable experience in design and implementation of complex software applications; prior experience in functional programming languages is preferred; * You continuously surprise us with your creative yet pragmatic solutions for complex software problems; * You are strongly committed to deliver working software as early as possible; * You work against very high quality standards. Refactoring is your bread and butter, pair-programming is how you prefer to review your code; * Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future; * Excellent command of written and spoken English. EDUCATION MSc, MEng, or PhD in Computer Science or significant relevant experience. ABOUT VECTOR FABRICS Vector Fabrics is a high-tech software company, developing tools for embedded multicore programming. Its technology and expertise is getting widespread recognition in the industry as being innovative and unique in their ability to address heterogeneous multicore application-specific silicon platforms. Due to the advanced nature of its tools, Vector Fabrics operates at the forefront of the next generation of embedded platforms for diverse markets ranging from supercomputers to automotive to cell phones. Vector Fabrics puts absolute priority on hiring top class individuals in key positions. Vector Fabrics’ team profile is exceptional and its ambition is to hire only individuals that match or surpass that profile. The company pays top salary and offers a challenging, engaging and stimulating work environment with a high degree of responsibility.

1 0

Array, Vector, Bytestring
by silvio 10 Jul '13

10 Jul '13

Hi everyone, Every time I want to use an array in Haskell, I find myself having to look up in the doc how they are used, which exactly are the modules I have to import ... and I am a bit tired of staring at type signatures for 10 minutes to figure out how these arrays work every time I use them (It's even worse when you have to write the signatures). I wonder how other people perceive this issue and what possible solutions could be. Eg. look at the type signature for changing a single entry in an array: * vector package: write :: PrimMonad m => MVector (PrimState m) a -> Int -> a -> m () * array package: writeArray :: (MArray a e m, Ix i) => a i e -> i -> e -> m () * bytestring package: not available * a reasonable type signature would be: write :: MVector a -> Int -> a -> ST s a # To many different implementations Why do we need so many different implementations of the same thing? In the ghc libraries alone we have a vector, array and bytestring package all of which do the same thing, as demonstrated for instance by the vector-bytestring package. To make matters worse, the haskell 2010 standard has includes a watered down version of array. I personally prefer the vector package but if you want to use libraries for strings, I am forced back to use bytesting. And now that Array was added to haskell 2010, that will start to pop up more and more. The multitude of already existing libraries is also why I am writing this to haskell-cafe and not spinning yet another implementation. # Index I don't really see a reason for having an index of a type other than Int and that starts somewhere else than at 0. While there might be corner cases where such a thing might be useful, it is only confusing and irritating for the (presumably) rest of us. # Storable vs Unboxed Is there really a difference between Storable and Unboxed arrays and if so can't this be fixed in the complier rather than having to expose this problem to the programmer? # ST s vs IO This is probably the hardest to resolve issue. The easiest solution is probably to just have a module for each of them as in the array package. I find the PrimState a bit complicated and circuitous. The ideal solution would be to have type IO a = ST RealWorld# a in the next haskell standard. If I understand it correctly this would let you declare the types as follows but and still use it in an IO context. write :: MVector a -> Int -> a -> ST s a Would this work? I know it would probably screw up all instances instance ... IO where On the other hand, this is not only an issue with arrays but all procedurally accelerated data structures like hash-tables. Silvio

12 24

Promoting Haskell via Youtube movies
by Mihai Maruseac 10 Jul '13

10 Jul '13

Hi, I was wondering if we have similar movies for Haskell as https://www.youtube.com/watch?v=kLO1djacsfg and https://www.youtube.com/watch?v=E3418SeWZfQ exist for Java. I indend to give them to some people to make them intrigued by the language and start learning it / looking for it. -- MM "All we have to decide is what we do with the time that is given to us"

9 9

Possible extension to Haskell overloading behavior
by Chris Smith 09 Jul '13

09 Jul '13

So I've been thinking about something, and I'm curious whether anyone (in particular, people involved with GHC) think this is a worthwhile idea. I'd like to implement an extension to GHC to offer a different behavior for literals with polymorphic types. The current behavior is something like: 1. Give the literal a polymorphic type, like (Integral a => a) 2. Type check the whole program, possibly giving the term a more constrained type. 3. If the type is still ambiguous, apply defaulting rules. I'd like to add the option to do this instead. 1. Take the polymorphic type, and immediately apply defaulting rules to get a monomorphic type. 2. Type check the program with the monomorphic type. Mostly, this would reduce the set of valid programs, since the type is chosen before considering whether it meets all the relevant constraints. So what's the purpose? To simplify type errors for programmers who don't understand type classes. What I have in mind is domain-specific dialects of Haskell that replace the Prelude and are aimed at less technical audiences - in my case, children around 10 to 13 years old; but I think the ideas apply elsewhere, too. Type classes are (debatably) the one feature of Haskell that tends to be tricky for non-technical audiences, and yet pops up in very simple programs (and more importantly, their error messages) even when the programmer wasn't aware of it's existence, because of its role in overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities.

2 7