February 2012 - Haskell-Cafe

empty fields are dropped in bytestring csv
by Tom Doris 18 Feb '12

18 Feb '12

the bytestring-csv package appears to have a bug whereby empty fields are dropped completely from the row, which is different to Text.CSV , which will return an empty field in the parse result. I'd argue this is a bug in bytestring-csv, anyone know whether this has been raised before, or know of a workaround? Prelude Data.Maybe Data.List Text.CSV.ByteString Data.ByteString.Char8> parseCSV $ pack "a,b,c\n1,2,3\n1,,9\n" Just [["a","b","c"],["1","2","3"],["1","9"]] -- the last row has two fields ^ Prelude Text.CSV> parseCSV "/tmp/err" "a,b,c\n1,2,3\n1,,9\n" Right [["a","b","c"],["1","2","3"],["1","","9"],[""]]

1 1

"Best" FRP package for newbie
by Arnaud Bailly 18 Feb '12

18 Feb '12

Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore "reactive" which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Thanks in advance for your help, Arnaud

5 5

BayHac '12
by Mark Lentczner 18 Feb '12

18 Feb '12

Please join us for a weekend of Haskell hacking: BayHac '12 April 20th ~ 22nd, 2012 Hacker Dojo Mountain View, CA This year will be concurrent with UHac in Utrecht, and technology willing, we'll be liking up to share the Hac between the continents! Full details on the Haskell Wiki: http://www.haskell.org/haskellwiki/BayHac2012 - Mark

1 0

ANN: unification-fd 0.6.0
by wren ng thornton 17 Feb '12

17 Feb '12

-------------------------------------------- -- unification-fd 0.6.0 -------------------------------------------- The unification-fd package offers generic functions for single-sorted first-order structural unification (think Prolog programming or Hindley--Milner type inference)[1][2]. I've had this laying around for a few years, so I figured I might as well publish it. An effort has been made to try to make this package as portable as possible. However, because it uses the ST monad and the mtl-2 package it can't be H98 nor H2010. However, it only uses the following common extensions which should be well supported[3]: Rank2Types MultiParamTypeClasses FunctionalDependencies -- Alas, necessary for type inference FlexibleContexts -- Necessary for practical use of MPTCs FlexibleInstances -- Necessary for practical use of MPTCs UndecidableInstances -- For Show instances due to two-level types -------------------------------------------- -- Changes (since 0.5.0) -------------------------------------------- * The kind of variables has been changed from *->* to *. Thus, the definition of MutVar is now exactly the free monad generated by t on v: data MutTerm v t = MutVar !v | MutTerm !(t (MutTerm v t)) This is a major API-breaking change, however it only affects the type level, and should only affect you if you're using the functions class-polymorphically or if you've defined your own variable types. -------------------------------------------- -- Description -------------------------------------------- The unification API is generic in the type of the structures being unified and in the implementation of unification variables, following the two-level types pearl of Sheard (2001). This style mixes well with Swierstra (2008), though an implementation of the latter is not included in this package. That is, all you have to do is define the functor whose fixed-point is the recursive type you're interested in: -- The non-recursive structure of terms data S a = ... -- The recursive term type type PureTerm = Fix S And then provide an instance for Unifiable, where zipMatch performs one level of equality testing for terms and returns the one-level spine filled with pairs of subterms to be recursively checked (or Nothing if this level doesn't match). class (Traversable t) => Unifiable t where zipMatch :: t a -> t b -> Maybe (t (a,b)) The choice of which variable implementation to use is defined by similarly simple classes Variable and BindingMonad. We store the variable bindings in a monad, for obvious reasons. In case it's not obvious, see Dijkstra et al. (2008) for benchmarks demonstrating the cost of naively applying bindings eagerly. There are currently two implementations of variables provided: one based on STRefs, and another based on a state monad carrying an IntMap. The former has the benefit of O(1) access time, but the latter is plenty fast and has the benefit of supporting backtracking. Backtracking itself is provided by the logict package and is described in Kiselyov et al. (2005). In addition to this modularity, unification-fd implements a number of optimizations over the algorithm presented in Sheard (2001)--- which is also the algorithm presented in Cardelli (1987). * Their implementation uses path compression, which we retain. Though we modify the compression algorithm in order to make sharing observable. * In addition, we perform aggressive opportunistic observable sharing, a potentially novel method of introducing even more sharing than is provided by the monadic bindings. Basically, we make it so that we can use the observable sharing provided by the previous optimization as much as possible (without introducing any new variables). * And we remove the notoriously expensive occurs-check, replacing it with visited-sets (which detect cyclic terms more lazily and without the asymptotic overhead of the occurs-check). A variant of unification which retains the occurs-check is also provided, in case you really need to fail fast for some reason. * Finally, a highly experimental branch of the API performs *weighted* path compression, which is asymptotically optimal. Unfortunately, the current implementation is quite a bit uglier than the unweighted version, and I haven't had a chance to perform benchmarks to see how the constant factors compare. Hence moving it to an experimental branch. These optimizations pass a test suite for detecting obvious errors. If you find any bugs, do be sure to let me know. Also, if you happen to have a test suite or benchmark suite for unification on hand, I'd love to get a copy. -------------------------------------------- -- Notes and limitations -------------------------------------------- [1] At present it does not appear amenable for higher-rank structural unification (a la HMF, MLF, or other System F type systems). The Dyna code from which this package was based had such features, though the previous implementation doesn't fit with the simplified model of unification used in this package. It's on my todo list, and if you have any suggestions, feel free to contact me. [2] At present it is only suitable for single-sorted (aka untyped) unification, a la Prolog. In the future I aim to support multi-sorted (aka typed) unification, however doing so is complicated by the fact that it can lead to the loss of MGUs; so it will likely be offered as an alternative to the single-sorted variant, similar to how the weighted path-compression is currently offered as an alternative. [3] With the exception of fundeps which are notoriously difficult to implement. However, they are supported by Hugs and GHC 6.6, so I don't feel bad about requiring it. Once the API stabilizes a bit more I plan to release a unification-tf package which uses type families instead, for those who feel type families are easier to implement or use. There have been a couple requests for unification-tf, so I've bumped it up on my todo list. -------------------------------------------- -- References -------------------------------------------- Luca Cardelli (1987) /Basic polymorphic typechecking/. Science of Computer Programming, 8(2):147--172. Atze Dijkstra, Arie Middelkoop, S. Doaitse Swierstra (2008) /Efficient Functional Unification and Substitution/, Technical Report UU-CS-2008-027, Utrecht University. <http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-027.pdf> Oleg Kiselyov, Chung-chieh Shan, Daniel P. Friedman, and Amr Sabry (2005) /Backtracking, Interleaving, and/ /Terminating Monad Transformers/, ICFP. <http://www.cs.rutgers.edu/~ccshan/logicprog/LogicT-icfp2005.pdf> Tim Sheard (2001) /Generic Unification via Two-Level Types/ /and Paramterized Modules/, Functional Pearl, ICFP. <http://web.cecs.pdx.edu/~sheard/papers/generic.ps> Tim Sheard & Emir Pasalic (2004) /Two-Level Types and/ /Parameterized Modules/. JFP 14(5): 547--587. This is an expanded version of Sheard (2001) with new examples. <http://web.cecs.pdx.edu/~sheard/papers/JfpPearl.ps> Wouter Swierstra (2008) /Data types a la carte/, Functional Pearl. JFP 18: 423--436. <http://www.cs.ru.nl/~wouters/Publications/DataTypesALaCarte.pdf> -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/unification-fd Darcs: http://community.haskell.org/~wren/unification-fd Haddock (Darcs version): http://community.haskell.org/~wren/unification-fd/dist/doc/html/unification… -- Live well, ~wren

2 2

[haskell-cafe] Some reflections on Haskell
by Doug McIlroy 17 Feb '12

17 Feb '12

Kevin Jardine notices "the full Haskell ecosystem ... is huge", and laments the absence of "a sophisticated IDE to help manage" it. Being a small-code type, I don't personally enjoy IDE's, which are undeniably useful in big projects, at the cost of a whole lot more to learn about "programmering" in addition to programming. Nevertheless, I share Jardine's concern about the central problem. It is hard to find one's way in this ecosystem. It needn't be, as Java illustrates. To my mind Java's great contribution to the world is its library index--light years ahead of typical "documentation" one finds at haskell.org, which lacks the guiding hand of a flesh-and-blood librarian. In this matter, it seems, industrial curation can achieve clarity more easily than open source. (To avoid entanglement with social media, this comment is going to Haskell Cafe rather than Google+ where other comments reside.) Doug McIlroy

8 7

Haskell implementation of a database?
by Vasili I. Galchin 17 Feb '12

17 Feb '12

Hello, I have been looking through Hackage database for a Haskell implementation of a database(not a binding) but couldn't find anything. Probably it was under my nose?? Vasili

3 2

"Good" Java book? (not off-topic)
by Ivan Perez 17 Feb '12

17 Feb '12

Hi, cafe, I find myself in the unusual position of having to recommend a few books on Java to people who want to use it professionally. As the people demanding this live in Burundi, I can't really say "Learn Haskell". Odds are they won't find a job there if they don't use mainstream languages. Is there any book on Java that approaches the language in a way that doesn't make programmers impervious to FP and Haskell? Not meaning to insult anybody here, I too learned Java before Haskell. But I also think it made learning Haskell much more difficult. Cheers, Ivan.

4 3

Command Line Tools for Xcode
by Lyndon Maydwell 17 Feb '12

17 Feb '12

Hi Café. Has anyone read the news at http://kennethreitz.com/xcode-gcc-and-homebrew.html? It looks like Apple is going to support a minimalist command-line based toolchain for Xcode called "Command Line Tools for Xcode" based on the OSX-GCC-Installer project. Would Haskell support this rather than requiring a full Xcode install? The requirement of Xcode has always struck me as quite onerous, however this weighs in at around 200M - Much nicer! I'm having issues logging in to the apple developer center at the moment and was wondering if anyone had tried it out. Thanks!

1 0

Compressed Data.Map for more efficient RAM usage?
by Jeremy Shaw 16 Feb '12

16 Feb '12

Sometimes we want to store very large collection types in RAM -- such as a Data.Map or Data.IxSet. It seems like we could trade-off some speed for space savings by compressing the values in RAM. Lemmih has previously created compact-map: http://hackage.haskell.org/package/compact-map which mightybyte used to create: https://github.com/mightybyte/compact-ixset compact-map converts the Haskell values to a more compact binary representation. But could we do even better by compressing the bytestrings? Here is a useless implementation: http://hpaste.org/63836 That version compresses each value by itself. But, that is probably going to be worse RAM usage, not better. I think what we really need to do is to store a dictionary in CMap that is used to compress all the ByteString values. That way if the same string appears in 10000 entries, they can all be compressed using the same compression code. One question is, how much would this benefit us? As an experiment I tried compressing one checkpoint file for real world acid-state app that I am involved with. A checkpoint file contains binary data that is serialized by the SafeCopy library. And it is data that is currently store in an IxSet in RAM. The uncompressed checkpoint file is 115MB. The compressed checkpoint file is 26MB. A checkpoint file probably contains more redundancy than an equivalent compressed IxSet because in addition to the values it also includes version tags and other easily compressed data. But, those numbers do look promising. At the very least, they do not rule out the possibility of some big savings. I do not have time to explore this anymore. But I think it could be a fun project for someone to work on. ;) I imagine a prototype with a shared dictionary could be hacked up in a few days. A bit more work would be required to document it, memory profile it, etc. If done well, we should be able to reuse the incremental compression code in Data.Map, Data.Set, Data.IxSet, HiggsSet, and other places. But, just focusing on Data.Map is a good start. I will create a bug in this bug tracker that links back to this message, http://code.google.com/p/happstack/issues/list - jeremy

3 4

Monadic bind fixity: do vs (>>)
by Michael Baikov 16 Feb '12

16 Feb '12

Most docs ([1], [2]) about do-notation syntactic sugar tends to describe following expressions as equivalent: "do { a; b; c }" and "a >> b >> c", but they are not: first one gets de-sugared into "a >> (b >> c)", second one is equivalent to "(a >> b) >> c", because (>>) is declared using infixl. This should not be a problem, monadic law of Associativity states that "(m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)", but this leads to generating different Core output and may lead to different performance (and it does, do { Just 4 ; Just 4 ... } is about 2% faster than Just 4 >> Just 4 >> ... if compiled with -O0, but 13% slower when compiled with -O11) This also leads to lots of fun when your monad breaks Associativity law :) Is there any reasons except for those 13% speed gain for this? [1]: http://en.wikibooks.org/wiki/Haskell/do_Notation [2]: http://book.realworldhaskell.org/read/monads.html#monads.dot

2 1