April 2010 - Haskell-Cafe

Re: Confusions about the Haskell Platform (for Mac)
by Gregory Collins 25 Apr '10

25 Apr '10

Yair Chuchem <yairchu(a)gmail.com> writes: > I don't have a good working solution for this, so the situation will > have to remain status quo (i.e. clicking two installers) for now. > > afaik you can make an "mpkg" installer that invokes/contains other > installers: > see http://developer.apple.com/Mac/library/documentation/DeveloperTools/Concept… If you can figure out how to take the binary package the GHC guys make and fold it into a larger .mpkg, please tell me. G. -- Gregory Collins <greg(a)gregorycollins.net>

1 0

Cabal generating text files?
by Michał J Gajda 25 Apr '10

25 Apr '10

Hi, Does anyone know how to generate a text file in a Cabal package? E.g. I want cabal to install a text file into $share_dir/applications/ app.desktop, and fill in certain fragments of this file with paths depending of the $share_dir variable. Say: ==============Yi.desktop template================== [Desktop Entry] Name=Yi Text Editor Comment=Edit text files, and add configuration in Haskell Comment[en_CA]=Edit text files, and configure editor in Haskell Comment[en_GB]=Edit text files, and configure editor in Haskell Comment[pl]=Edytor plików tekstowych z konfiguracją w Haskellu TryExec=$yi_bindir/bin/ yi Exec=$yi_bindir/bin/yi -f %F Terminal=true Type=Application Icon=$yi_sharedir/share/art/yi +lambda.svg Categories=Utility;TextEditor; StartupNotify=false MimeType=text/plain; =============================================== Sorry I couldn't find it in Cabal documentation. -- Best regards Michal

2 1

FGL up for adoption
by Martin Erwig 24 Apr '10

24 Apr '10

Dear FGL users and contributors, The FGL seeks a new home. I don't really have the time anymore to maintain the FGL and add new components at a level that it deserves. I am therefore looking for someone (or a group of people) who would be interested in taking over the maintenance and future development. Anybody interested? Thanks, Martin

3 3

Second Ghent Functional Programming Group Meeting: Date and Call for Talks
by Jeroen Janssen 24 Apr '10

24 Apr '10

(apologies if you receive multiple copies) Dear all, The second Ghent Functional Programming Group (Ghent FPG) meeting takes place on Thursday, May 13 at 19:00 in the Technicum building of Ghent University (Sint-Pietersnieuwstraat 41, 9000 Gent). We have a number of 20-minute timeslots (excluding questions) available for talks, so if you are interested in giving a talk you can e-mail Jeroen Janssen (jejansse(a)gmail.com) The final program will be announced shortly. Hope to see you all then, Bart Coppens (Bart.Coppens(a)elis.ugent.be; Twitter: @BartCopp) Jasper Van der Jeugt (jaspervdj(a)gmail.com; Twitter: @jaspervdj) Jeroen Janssen (jejansse(a)gmail.com; Twitter: @jejansse) Note: if you do not want to receive any more e-mails from Ghent FPG, just send an e-mail to Jeroen Janssen (jejansse(a)gmail.com) and we will remove you from our mailinglist.

1 0

Re: [Haskell-cafe] Using a library in a executable within same cabal package
by Arnaud Bailly 24 Apr '10

24 Apr '10

You are right, I hit "reply" without checking the destination. Thanks for your answer. Arnaud On Sat, Apr 24, 2010 at 3:24 PM, Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > First of all, did you mean to reply back to -cafe as well? > > Arnaud Bailly <arnaud.oqube(a)gmail.com> writes: > >> I was not precise enough: Yes, I found the examples to have both a >> library and an executable clear enough that I managed to have >> something workable. But I found somewhat surprisingly that the modules >> used in both the library and the executable were compiled twice. I was >> expecting the executable to link to the dynamic library produced. >> I understand from your answer this is a known issue. > > Right; with Cabal 1.8 this situation is "solved", but at the expense of > not being able to build documentation (I think I was the first person to > fully try this, which is why the bug went unnoticed until recently; the > darcs people are considering using it as well but they didn't test > building haddock docs). > > So yeah, at the moment you're stuck with building the library multiple > times :s > >> >> On Sat, Apr 24, 2010 at 12:14 PM, Ivan Lazar Miljenovic >> <ivan.miljenovic(a)gmail.com> wrote: >>> Arnaud Bailly <abailly(a)oqube.com> writes: >>>> Not sure this question is totally on-topic. >>> >>> Sure is. >>> >>>> Please point me in the right direction if it is not. I would like to >>>> make a cabal package containing both an executable and several >>>> libraries, >>> >>> Each cabal package can contain only one library (which is why gtk2hs is >>> only now starting to be cabalised). >>> >>>> and link the main executable to the libraries produced in >>>> the build. It is not clear how I can achieve that from the >>>> documentation. I tried Extra-libraries option but it does not work. >>> >>> By default, you don't need to do anything extra to have executables >>> using a library in the same package (assuming they have the same source >>> directory) as GHC will find all the modules it needs. >>> >>> Cabal-1.8 has a new feature that lets executables explicitly depend upon >>> the libraries, which means the library doesn't need to get rebuilt >>> several times. However, this is causing problems with building haddock >>> documentation: http://hackage.haskell.org/trac/hackage/ticket/656 >>> >>> -- >>> Ivan Lazar Miljenovic >>> Ivan.Miljenovic(a)gmail.com >>> IvanMiljenovic.wordpress.com >>> > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic(a)gmail.com > IvanMiljenovic.wordpress.com >

1 0

Compressing GHC tarballs with LZMA
by Leon Smith 24 Apr '10

24 Apr '10

Out of curiousity, I downloaded a binary distribution for GHC-6.12.2, and tried compressing and recompressing it with bzip2 and lzma compression, using no command line arguments (all default parameters) file: http://haskell.org/ghc/dist/6.12.2/ghc-6.12.2-x86_64-unknown-linux-n.tar.bz2 bzip2 lzma size 106M 72M compression time 2:01 9:51 decompression time 0:25 0:12 the time is reported as "minutes:seconds". At it default compression level, lzma was almost five times slower than bzip2, but it's approximately twice as fast when decompressing and produced a file nearly a third smaller. Given that many modern variants of the "tar" command support .tar.lzma files directly, and that both debian's dpkg and red hat's rpm now use lzma, maybe it's time to consider offering .tar.lzma as a download option for GHC's binary (and maybe source-code) bundles. Best, Leon

6 5

Using a library in a executable within same cabal package
by Arnaud Bailly 24 Apr '10

24 Apr '10

Hello, Not sure this question is totally on-topic. Please point me in the right direction if it is not. I would like to make a cabal package containing both an executable and several libraries, and link the main executable to the libraries produced in the build. It is not clear how I can achieve that from the documentation. I tried Extra-libraries option but it does not work. Thanks for your help -- Arnaud Bailly

3 2

Re: [Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers
by John Lato 23 Apr '10

23 Apr '10

> From: "Barak A. Pearlmutter" <barak(a)cs.nuim.ie> > >> ... An invalid comparison evaluating to _|_ is arguably more >> correct, but I personally find the idea of introducing more bottoms >> rather distasteful. > > Too late! NaN is pretty much the _|_ of IEEE Floating Point. > > That was certainly the intent of the IEEE standard, and is why NaN is > so contagious. But they wanted to relax the usual strictness of their > languages (FORTRAN, C) when this particular _|_ is around. So NaN is > contagious through strict arithmetic (+, *, etc) like _|_. But it has > strange behaviour with respect to comparison. In the context of > Haskell, which does not have the issue of needing to relax strictness > just for NaN, I think the "right thing" would be to have compare give > _|_, and maybe also <, >, ==. After all, NaN is outside the carefully > defined total ordering of all other IEEE floating point values > including +/- Infinity. +1 John

1 0

Re: [Haskell-cafe] lazy-vs-strict, recursive IO (was: memory needed for SAX parsing XML)
by John Lato 23 Apr '10

23 Apr '10

(changed the thread title hoping to get some others to weigh in on the recursive I/O scheme presented here) > From: Daniil Elovkov <daniil.elovkov(a)googlemail.com> > John Lato wrote: >> >>> Another (additional) approach would be to encapsulate unsafeInterleaveIO >>> within some routine and not let it go out into the wild. >>> >>> lazilyDoWithIO :: IO a -> (a -> b) -> IO b >>> >>> It would use unsafeInterleave internally but catch all IO errors within >>> itself. >>> >>> I wonder if this is a reasonable idea? Maybe it's already done? >>> So the topic is shifting... >> >> doWithIO :: NFData b => IO a -> (a -> b) -> IO b >> doWithIO m f = liftM (\a -> let b = f a in b `deepseq` b) m >> >> It works (just stick it in a "try" block for error handling), but you >> need to write a lot of NFData instances. You also need to be careful >> that b is some sort of reduced structure, or you can end up forcing >> the whole file (or other data) into memory. > > I meant a different thing. In your example there is no unsafeInterleave > at all. I think you mean that 'm' argument is supposed to be an > unsafeInterleaved io action, like getContents, and deepseq'ing saves us > from it hanging somewhere for a long time. Ok Yes, that's what I intended. I understand now that it isn't what you meant. > > But I meant to have a routine that lets us use ordinary io actions in a > lazy way, and restricting that 'hanging' within bounds of this routine. > > But having thought about it a little more I understood that it's impossible. I think it's possible provided you have unsafeInterleaveIO and deepseq. As you discovered, to force evaluation through an unsafeInterleaveIO you need to fully evaluate data, and deepseq is the way to do so. > > Lazy io works now because unsafeInterleaveIO is sticked into getContents > itself, and is called repeatedly (via recursion). Or at least I can > think of this implementation, haven't looked into it. > > I realised that calling unsafeInterleaveIO for an ordinary io action > will not make it run lazily. It will, still, run all-at-once, just not > now, but later. Yes, exactly. unsafeInterleaveIO needs to be used recursively for getContents to function properly. > > So, to cope with it, I can think of exposing a little structure of an io > action. Normally it's completely opaque. But if we knew where its > recursion point lies, then we could control its course of execution. > > So, if we had something like > type RecIO a = IO a -> IO a > and io actions were like > getContents :: RecIO [Char] > getContents rec = do > c <- readOneChar > rest <- rec > return (c:rest) > > then we could either run them > normally :: RecIO a -> IO a > normally r = r (normally r) > or > lazily :: RecIO a -> IO a > lazily r = unsafeInterleavIO $ r (lazily r) > > And > lazilyDoWithIO :: RecIO a -> (a -> b) -> IO b > lazilyDoWithIO m f = do > a <- lazily m > return $ f a > > Hmm, but then, we would have to take special care to not let it out of > this function anyway... So here we come to deepSeq'ing you proposed. I think my understanding matches yours at this point, except I'm not sure I follow RecIO. Your getContents, for example, seems to only read one character. I think you mean something like this? recGetContents :: RecIO String recGetContents rec = do c <- getChar ise <- isEOF if ise then return [c] else liftM (c:) rec normally :: RecIO a -> IO a normally = fix lazily :: RecIO a -> IO a lazily rec = let f = unsafeInterleaveIO (rec f) in f This works, but I'm not sure that it accomplishes anything. (it doesn't work in ghci because EOF isn't sent through the terminal, but if you test for another character it works fine). > > And anyway, instead of re-writing pure functions to become iteratees we > will have to re-write io functions to adopt continuation passing style. > > Initially it looked better to me :) Re-writing pure functions to be iteratees doesn't have to be hard; many of the provided iteratees have the same names as standard functions so a lot of the work can be done by just changing imports. > > But with this approach we can run lazily any io action that has the form > of RecIO. Also, we can interleave normally and lazily based on the time > of day and other conditions :) > Originally I didn't see much use to this scheme, but I'm starting to change my mind. It would be nice for users to be able to control the evaluation of functions like getContents, hGetContents, etc., and this looks like it could be easier to maintain. > >> It also doesn't help with >> other IO effects, e.g. writing output. I consider this one of the >> nicest features of iteratee-based processing. > > Can you clarify what's the problem with writing? I think I just haven't > switched from the topic of gluing code. > > Because as for gluing code, type signature for io writing d -> IO () is > perfectly sufficient. The problem isn't with writing output per se, but with sequencing I/O effects with lazy data processing. If you wanted to write to a log file after processing each 100kbytes of a file, for example, doing so with bytestrings would require manually chunking the string, creating output, etc., which then hampers both modularity and readability. Adding this sort of monadic side-effect while data is only partially evaluated is pretty simple with iteratees. Actually, this recursive IO combinator idea you've sketched out would be somewhat helpful in this regard too. John

1 0

Re: [Haskell-cafe] memory needed for SAX parsing XML
by John Lato 23 Apr '10

23 Apr '10

> Message: 8 > Date: Tue, 20 Apr 2010 12:08:36 +0400 > From: Daniil Elovkov <daniil.elovkov(a)googlemail.com> > Subject: Re: [Haskell-cafe] memory needed for SAX parsing XML > To: Haskell-Cafe <haskell-cafe(a)haskell.org> > Message-ID: <4BCD6104.50508(a)googlemail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Jason Dagit wrote: >> >> >> On Mon, Apr 19, 2010 at 3:01 AM, Daniil Elovkov >> <daniil.elovkov(a)googlemail.com <mailto:daniil.elovkov@googlemail.com>> >> wrote: > >> I think iteratees are slowly catching on as an alternative to lazy io. >> Basically, the iteratee approach uses a left fold style to stream the >> data and process it in chunks, including some exception handling. >> Unfortunately, I think it may also require a special sax parser that is >> specifically geared towards iteratee use. Having an iteratee based sax >> parser would make processing large xml streams very convenient in >> haskell. Hint, hint, if you want to write a library :) (Or, maybe it >> exists, I admit that I haven't checked.) > > > Iteratees seem like a natural thing if we want to completely avoid > unsafeInterleaveIO. But the presence of the latter is so good for > modularity. > > We can glue IO code and pure code of the type String -> a so seamlessly. > In case of iteratees, as I understand, pure functions of the type String > -> a would no longer be usable with IO String result. The signature (and > the code itself) would have to be changed to be left fold. To some extent, yes, although the amount of work required can vary. The general rule of thumb is that functions can be used directly with iteratees if they can work strictly. Functions that rely on laziness need some adaptation, although how much varies. If you've built your string handling functions out of a parser combinator library, e.g. parsec-3 or attoparsec, you can just lift the parser into an iteratee and use all your existing functions. Since you're using HaXml, this should work. The only missing part is a polyparse-iteratee converter. I haven't used polyparse, but it looks like the converter would be similar to the one used for attoparsec in the attoparsec-iteratee package. That said, it's not how I would do it. Since SAX is a stream processor, an iteratee-based SAX implementation would be a good fit. I would write a lexer and parser (using a parser combinator library) and then use those with Data.Iteratee.convStream. That's how I would write an iteratee-based SAX parser. HaXml already includes a suitable lexer and parser, but unfortunately they're not exposed. > > Another (additional) approach would be to encapsulate unsafeInterleaveIO > within some routine and not let it go out into the wild. > > lazilyDoWithIO :: IO a -> (a -> b) -> IO b > > It would use unsafeInterleave internally but catch all IO errors within > itself. > > I wonder if this is a reasonable idea? Maybe it's already done? > So the topic is shifting... doWithIO :: NFData b => IO a -> (a -> b) -> IO b doWithIO m f = liftM (\a -> let b = f a in b `deepseq` b) m It works (just stick it in a "try" block for error handling), but you need to write a lot of NFData instances. You also need to be careful that b is some sort of reduced structure, or you can end up forcing the whole file (or other data) into memory. It also doesn't help with other IO effects, e.g. writing output. I consider this one of the nicest features of iteratee-based processing. John

2 1