April 2010 - Haskell-Cafe

Data instance for a GADT
by Ozgur Akgun 25 May '10

25 May '10

Cafe, How can I provide a Data instance for a GADT? I am trying to TH on it, and Uniplate requires Data. I tried StandaloneDeriving, but it seems not to work. Best, -- Ozgur Akgun

3 4

What do _you_ want to see in FGL?
by Ivan Lazar Miljenovic 19 May '10

19 May '10

Since I've volunteered myself to help maintain/upgrade FGL, what do the people in the community want to see happen with it? Here are some ideas that I have regarding FGL: * I had already started working on a new generic graph class [1] (with initial draft at [2]) to act as a wrapper around FGL and other graph implementations. However, if I'm going to be updating FGL anyway I might as well combine the two and generalise/update FGL instead. Generally speaking, this will involve the following items: - Splitting and expanding the typeclasses involved; most class methods would have default definitions but this will allow people to override the defaults if there's a more efficient way for their datatype. - Having a separate parameter (using associated types?) for the node type rather than just using Int. - Providing more "fundamental" graph operations that may be of use. However, the downside of this is that datatypes such as Data.Graph in containers won't match this anymore due to the lack of node and edge labels. I think this fair price to pay, especially if the mapping aspects are split off into another typeclass. [1]: http://www.haskell.org/pipermail/haskell-cafe/2009-June/063402.html [2]: http://code.haskell.org/~ivanm/Graph.hs * Better fundamental data structures: one of the things that has always annoyed me about FGL is how much it uses tuples; I propose re-defining the Context type to be a record-based data structure. Also, usage of Sets, Maps, etc. where applicable. * Proper instances: make graphs instantiate Eq, Ord, Show and Read (where read . show == id). The Show and Read instances will probably usually be like how Data.Map has them, so helper functions can be defined to help out with this. * Split off the instances: maybe keep one basic graph datatype in FGL, but then have separate packages for others (which means its easier to add new datatypes without needing a new release, etc.). * Split off the various Data.Graph.Inductive.Query functions/algorithms, and merge in the ones I have defined in Graphalyze [3]. [3]: http://hackage.haskell.org/package/Graphalyze * Scrap Data.Graph.Inductive.Graphviz and recommend usage of my graphviz library [4] instead. [4]: http://hackage.haskell.org/package/graphviz * Data.Graph.Inductive.Monad: does anyone actually use this? * Benchmarks and tests. What do other people think? Any other suggestions? Also, once I release the next version of graphviz (hopefully later today), I was going to work on improving SourceGraph [5] by providing command line options, etc. to it; would people prefer I work on FGL instead? [5]: http://hackage.haskell.org/package/SourceGraph -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

9 48

ANN: precis-0.3.1 - Cabal package diff tool
by Stephen Tetley 13 May '10

13 May '10

Hello all I've upload precis to Hackage - a diff tool for Cabal packages. It compares two cabal files looking at changes to the exposed and internal modules lists, then diffs the exposed modules. It only works on extant .hs files - i.e. it won't work on .hsc files. Also, I haven't tested if it works on .lhs files - parsing is left to haskell-src-exts. When it diffs new and old revisions of an exposed module it should report: - changes to the export list - changes to instance declarations - changes to exported data declarations - changes to the exported type signatures of exported functions The report it produces is not very pretty. A declaration is marked as *conflict* if its textual representation has changed - I compare the string output from pretty printing the new and old versions rather than look deeply into the AST. Though low-tech, this seems to work well in practice. I expect there are some bugs... Thanks to Malcolm Wallace for CppHs, and Niklas Broberg for haskell-src-exts. Best wishes Stephen

4 8

GHC 6.12 on OS X 10.5
by Conor McBride 08 May '10

08 May '10

Hi I thought I'd record my upgrade exerience (so far) in case anyone else finds it useful, and (more selfishly) in case anyone has some helpful advice. Summary of situation * I got 6.12 working. * It took a lot of fumbling around. * The eventual "fix" (renaming /opt/local/lib/libiconv.dylib) was a bit dodgy, but is holding for now. Long rambling narrative follows. Various features of GHC 6.12 made it very tempting to go for an earlier upgrade than I normally would. (SHE really needs GADT-style data families; everything I do needs deriving Traversable (deriving HalfZip would be nice too!).) Already there was a handy installer for Intel+Leopard macs (is anybody on the PPC+Leopard case? if not, I will be soon...). I thought "go for it". Installation, no problem. Compiling something: whoops, no mtl. OK, cabal install mtl: whoops, no acceptable cabal. Fair dos, if I'd read the warnings I'd have known that my cabal-install would be useless and tried to build the new one. QUESTION: Is the sensible upgrade path to build cabal-install 0.8 with your old GHC, before installing 6.12? Does this even work? At one point, I tried this and had some peculiar issues involving zlib... Anyhow, I've got 6.12 and I need cabal-install 0.8. Can I find it? Tricky, and http://haskell.org/cabal/ didn't help much. I'm very tolerant of busy people not quite getting round to it, and I can use google, so I find the darcs version and get cracking. This happens: ----------------------------------------------------------------------------- bash-3.2$ ./bootstrap.sh Checking installed packages for ghc-6.12.1... parsec-2.1.0.1 will be downloaded and installed. network-2.2.1.5 will be downloaded and installed. Cabal is already installed and the version is ok. mtl-1.1.0.2 will be downloaded and installed. HTTP-4000.0.8 will be downloaded and installed. zlib-0.5.2.0 will be downloaded and installed. Downloading parsec-2.1.0.1... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 15430 100 15430 0 0 12743 0 0:00:01 0:00:01 --:--:-- 19312 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... Undefined symbols: "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) "_iconv", referenced from: _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) ld: symbol(s) not found collect2: ld returned 1 exit status Error during cabal-install bootstrap: Compiling the Setup script failed ----------------------------------------------------------------------------- At lthis point, I suspected a linker/dylib problem, but foolishly, I wanted the problem to be pretty much anything else, so I spent far too long looking the wrong way. I thought that if I could just get cabal-install working somehow, I'd be ok. I tried installing parsec with runhaskell Setup.hs {configure,build,install} but each of these commands appeared content to do precisely nothing: I found this perplexing. I tried reverting to 6.10.4 and compiling cabal-install. This made more progress, but died with some sort of zlib version snafu. (I'm sorry, I should have recorded the details but didn't.) The zlib-0.5.2.0 package did install successfully, but somehow the build for cabal-install itself went awry with an "even though this is the right version I can't find X" sort of a problem. I uninstalled 6.10.4, deleted my .cabal directory, nuked a few other relics showing up from what's probably a dumb choice of PATH setting. I had another go at 6.12, and this time I tried compiling a wee program of my own with no exciting package dependencies. Should have done that straight away, of course. Same iconv problem. This left no alternative. I found I had a /usr/lib/libiconv.dylib etc and an /opt/local/lib/libiconv.dylib etc, so I renamed the latter to opt/local/lib/moolibiconv.dylib, and suddenly, GHC became capable of linking stuff. The darcs version of cabal-install then built just fine; SHE rebuilt ok; Epigram needed a few extra LANGUAGE pragmas, but no trouble. I'm almost back where I was. I worry about this. (1) What have I broken by shifting the opt/local/lib copy of libiconv? (2) Why did that break things anyway? (3) How come I ended up with a broken library setup? (4) What else is broken? (What's worse than finding a maggot in your apple? Finding half a maggot in your apple.) I'm not at all a mac expert (I use a mac because I'm too stupid to maintain a linux installation -- the Nottingham grad students (all grown up now) told me they were fed up fixing my computer back in 04.) This dylib nonsense seems quite common. Is it MacPorts messing things up? Is there a more principled fix than the brutal thing I did? I wonder if it might be possible to build some sort of diagnostic tool to check paths and libraries for conflicts and omissions. Anyhow, sorry for the dreariness of this story, but it ends in an acceptable configuration, for the moment. I hope it can be of some small help. Happy hols Conor

10 19

accents
by Dupont Corentin 07 May '10

07 May '10

Hello, i have a list of french words with accents. How could i handle them? If i load them with ghci i get: > a <- readFile "list.txt" > head $ lines a "abn\233gation" putStrLn displays a strange character for the "é". Cheers, Corentin

3 4

Haskell XML Parsers
by R Senington 06 May '10

06 May '10

Dear all, I have been looking at using XML for a little program I have been writing. The file I am currently trying to load is about 9MB, and I have now tried to use HaXml and HST. Without any of my own code, just a simple call to the basic parsers, they both use huge amount of memory. HST is the worst and about 7GB and climbing. HaXml uses 1.3Gb. The code I am using is HST xml <- readFile file_name_here;k<-runX (parseXmlDocument True) xml;print k and for HaXml x<-readFile file_name_here let (Document _ _ e _) = xmlParse "t" x let t = myFilter $ CElem e print $ length t I have seen on previous posts to the cafe that other people have run into this problem with HST. Is this a general problem with XML in Haskell (I know that XML parsing is a slow and bulky process but this seems excessive)? Is there a known solution? Does anyone have any advice? Cheers RS

4 4

Installing ghc in an OpenSolaris Zone
by Günther Schmidt 04 May '10

04 May '10

Hello, has anyone yet managed to install ghc (6.10.4) into an OpenSolaris zone? Günther

3 6

Building regex-posix for windows
by Станислав Черничкин 03 May '10

03 May '10

I'm having trouble building regex-posix for Windows under MinGW because MinGW does not include regex.h. As far as I know Haskell Platform uses MinGW and it includes regex-posix. I'd like to build regex-posix by myself, like Haskell Platform does. I would appreciate it if someone suggests some resources about building regex-posix and other packages for windows. I’m also looking for Haskell Platform developer’s blog or something similar, where I can read about porting Haskell on Windows. Thanks.

7 7

Re: FRP for game programming / artifical life simulation
by Ben 03 May '10

03 May '10

slightly off topic, but how does one handle pausing / saving / restarting in the FRP framework, especially the arrowized version? i've only been able to do this via explicit (or monadic) state-passing, e.g. imperative / piecemeal versus declarative / wholemeal, which seems against the spirit of FRP. b

12 25

FRP for game programming / artifical life simulation
by Ben Christy 03 May '10

03 May '10

I have an interest in both game programming and artificial life. I have recently stumbled on Haskell and would like to take a stab at programming a simple game using FRP such as YAMPA or Reactive but I am stuck. I am not certain which one I should choose. It seems that Reactive is more active but is it suitable for game programming. Also has anyone attempted to implement neural networks using FRP if so again which of these two approaches to FRP would you suggest?

6 7