- Haskell-Cafe - Haskell.org

System.Mem.performGC leaks?
by Neal Alexander 25 Jul '09

25 Jul '09

main = forever performGC The OS reported memory usage skyrockets. If i enable +RTS -S the GC statistics show the heap "live bytes" being constant. Is it accumulating statistics even when profiling is disabled (and can you turn that off), or is there something going on with the FFI call to performGC. Compiled with "ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded" btw.

2 4

Haskell on a VPS
by John Van Enk 25 Jul '09

25 Jul '09

Has any one used a service similar to (or equivelant to) Slicehost or Linode to run Haskell network applications?

7 11

Re:Haskell-Cafe Digest, Vol 71, Issue 30
by silent_stream 24 Jul '09

24 Jul '09

When I compile curl-1.3.5 on Windows xp. I run the prompt "runghc Setup.hs configure " I got the following error Setup.hs: Missing dependency on a foreign library: * Missing C library: curl This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. I don't know how to fix this problem. Who knows? Please come to help me . 在2009-07-21 09:43:45，haskell-cafe-request@haskell.org 写道： >Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe >or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > >You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Haskell-Cafe digest..." > > >Today's Topics: > > 1. Hackage and version control (Vasili I. Galchin) > 2. FFI problem - possibility of CStringLen overflow? (Robin Green) > 3. Re: FFI problem - possibility of CStringLen overflow? > (Bulat Ziganshin) > 4. Re: Hackage and version control (Magnus Therning) > 5. Re: was: Debugging methods for haskell structured data types > the right way in haskell (Jon Fairbairn) > 6. Re: Hackage and version control (Bulat Ziganshin) > 7. Re: Hackage and version control (Robin Green) > 8. Re: Hackage and version control (Miguel Mitrofanov) > 9. Re: Hackage and version control (Joe Fredette) > 10. Re: Hackage and version control (Wolfgang Jeltsch) > 11. Re[2]: [Haskell-cafe] Hackage and version control > (Bulat Ziganshin) > 12. Re: ANN: cautious-file 0.1.1: Ways to write a file > cautiously, to avoid data loss (Robin Green) > 13. Re: Implicit concatenation in list comprehensions (Roel van Dijk) > 14. Re: ANN: cautious-file 0.1.1: Ways to write a file > cautiously, to avoid data loss (Felipe Lessa) > 15. Typeclass default implementation in subclasses (Andy Gimblett) > 16. ICFP contest write-up (Rafael Gustavo da Cunha Pereira Pinto) > 17. SpecConstr difficulties (Reiner Pope) > 18. Re: Typeclass default implementation in subclasses (Roel van Dijk) > 19. ANNOUNCE: graphviz-2999.1.0.1 (Ivan Lazar Miljenovic) > 20. Re: Implicit concatenation in list comprehensions (Roel van Dijk) > 21. RE: Implicit concatenation in list comprehensions > (Sittampalam, Ganesh) > 22. Re: Implicit concatenation in list comprehensions (Roel van Dijk) > 23. Re: FFI problem - possibility of CStringLen overflow? > (Jason Dagit) > 24. Anglohaskell - wifi signups (Philippa Cowderoy) > 25. Pruning the Front Page (Thomas DuBuisson) > 26. Re: Pruning the Front Page (Don Stewart) > 27. Re: Implicit concatenation in list comprehensions > (Max Bolingbroke) > 28. Re: Ambiguous type variable - help! (phil(a)beadling.co.uk) > 29. Re: Implicit concatenation in list comprehensions > (Nicolas Pouillard) > 30. Re: Implicit concatenation in list comprehensions (porges(a)porg.es) > 31. Re: Pruning the Front Page (Gwern Branwen) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 20 Jul 2009 03:26:52 -0500 >From: "Vasili I. Galchin" <vigalchin(a)gmail.com> >Subject: [Haskell-cafe] Hackage and version control >To: haskell-cafe(a)haskell.org >Cc: Galchin Vasili <vigalchin(a)gmail.com> >Message-ID: > <5ae4f2ba0907200126j56a497earb06ae885dbb7bb81(a)mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Hello, > > It seems to me that Hackage doesn't provide version control, e.g. check >out and check in. Am I incorrect? > >Kind regards, Vasili >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090720/9a2c1cb3… > >------------------------------ > >Message: 2 >Date: Mon, 20 Jul 2009 03:24:49 +0100 >From: Robin Green <greenrd(a)greenrd.org> >Subject: [Haskell-cafe] FFI problem - possibility of CStringLen > overflow? >To: haskell-cafe(a)haskell.org >Message-ID: <20090720032449.690fdf47@fedora> >Content-Type: text/plain; charset=US-ASCII > >While rewriting cautious-file to use ByteStrings and FFI just now, I >came across this potential problem: > >Why does the FFI specification define CStringLen as (Ptr CChar, Int)? >As the FFI specification itself notes, Haskell 98 implementors are >allowed to have a quite small range for Int (only up to 2^29-1) - so you >could in principle have a very large String which cannot be represented >as a CStringLen, or a very large CString which cannot be represented as >a CStringLen. They would take up wads of memory, so this has probably >never happened yet, but it's in principle possible, no? > >If so, what are the implications of this for code correctness? >-- >Robin > > >------------------------------ > >Message: 3 >Date: Mon, 20 Jul 2009 12:49:38 +0400 >From: Bulat Ziganshin <bulat.ziganshin(a)gmail.com> >Subject: Re: [Haskell-cafe] FFI problem - possibility of CStringLen > overflow? >To: Robin Green <greenrd(a)greenrd.org> >Cc: haskell-cafe(a)haskell.org >Message-ID: <1096519401.20090720124938(a)gmail.com> >Content-Type: text/plain; charset=us-ascii > >Hello Robin, > >Monday, July 20, 2009, 6:24:49 AM, you wrote: > >> Why does the FFI specification define CStringLen as (Ptr CChar, Int)? > >1. i think it was done to simplify using the api >2. hugs usually don't used for data-massive apps, it's niche is learning and >quick development > >-- >Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > >------------------------------ > >Message: 4 >Date: Mon, 20 Jul 2009 10:03:56 +0100 >From: Magnus Therning <magnus(a)therning.org> >Subject: Re: [Haskell-cafe] Hackage and version control >To: "Vasili I. Galchin" <vigalchin(a)gmail.com> >Cc: haskell-cafe(a)haskell.org >Message-ID: > <e040b520907200203w2f6392acy62e6571899866253(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Mon, Jul 20, 2009 at 9:26 AM, Vasili I. Galchin<vigalchin(a)gmail.com> wrote: >> Hello, >> >> Â Â Â Â It seems to me that Hackage doesn't provide version control, e.g. check >> out and check in. Am I incorrect? > >Hackage is, AFAIU, a repository where _released_ versions of >libraries/tools/etc related to Haskell can be kept. It is not fully >comparable to SourceForge, Github, or any other _source hosting_ >service. > >If you are looking for source hosting then take a look at SF, Github, >Google Code, or something like that. Then upload _released_ versions >to Hackage. IIRC there is also the possibility of having a Darcs repo >on community.haskell.org. > >/M > >-- >Magnus Therning (OpenPGP: 0xAB4DFBA4) >magnusï¼ therningï¼org Jabber: magnusï¼ therningï¼org >http://therning.org/magnus identi.ca|twitter: magthe > > >------------------------------ > >Message: 5 >Date: Mon, 20 Jul 2009 10:26:02 +0100 >From: Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> >Subject: [Haskell-cafe] Re: was: Debugging methods for haskell > structured data types the right way in haskell >To: haskell-cafe(a)haskell.org >Message-ID: <wfd47viu39.fsf(a)calligramme.charmers> >Content-Type: text/plain; charset=utf-8 > >Fernan Bolando <fernanbolando(a)mailc.net> writes: > >> On Sun, Jul 19, 2009 at 7:40 AM, wren ng thornton<wren(a)freegeek.org> wrote: >>> Fernan Bolando wrote: >>>> >>>> The intention is z0 is a system parameter and database, it contains a >>>> set of info needed to define a particular simulation >>> >>> A single-constructor ADT, especially with the labeled-fields syntax, is >>> pretty close to C structs; no need to reinvent them and give yourself >>> headaches. >>> >>> >>> Really, the only thing you should be using lists for is a variable-length >>> sequence of elements drawn from the same type and distinguished only by >>> their position in the sequence. >> >> This is the kind of code recommendations I was looking. > >I'd worked out a longer reply over the weekend, but wren got there first >(It hadn't occured to me that anyone would write that much code without >knowing about algebraic types, so thought something else was going on). > >I'd like to add that thinking about the C code for a programme like this >is counterproductive. If you are doing various mathematical operations, >it's better to go straight from the mathematics to Haskell, and work out >the appropriate abstractions (in Haskell) for the operations you are >using. You'll generally end up with much shorter code that is easier to >maintain. > >It might be worth pointing out that you can do things with Haskell data >structures that you can't do conveniently in C. For example, if you were >doing something that involved calculating the determinants of matrices >fairly often, but you didn't know in advance which matrices, you could >define your own matrix type like this (roughly): > >data MyMatrix t = MM {theNumbers:: Matrix t, my_determinant:: t} > >make_matrix m > = MM {theNumbers = m, > my_determinant = determinant m > } > >and then use make_matrix whenever you make a new matrix and >my_determinant whenever you want a determinant. > >Now, although to a C programmer this looks like you calculate the >determinant of every matrix, laziness means that you only calculate the >ones you use, and calculate them at most once for each matrix. > > >-- >JÃ³n Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk > > > > >------------------------------ > >Message: 6 >Date: Mon, 20 Jul 2009 13:27:06 +0400 >From: Bulat Ziganshin <bulat.ziganshin(a)gmail.com> >Subject: Re: [Haskell-cafe] Hackage and version control >To: "Vasili I. Galchin" <vigalchin(a)gmail.com> >Cc: haskell-cafe(a)haskell.org >Message-ID: <1393740130.20090720132706(a)gmail.com> >Content-Type: text/plain; charset=iso-8859-1 > >Hello Vasili, > >Monday, July 20, 2009, 12:26:52 PM, you wrote: > >> It seems to me that Hackage doesn't provide version control, >> e.g. check out and check in. Am I incorrect? > >i recommend you to use either codeplex or code.google > > >-- >Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > >------------------------------ > >Message: 7 >Date: Mon, 20 Jul 2009 04:25:25 +0100 >From: Robin Green <greenrd(a)greenrd.org> >Subject: Re: [Haskell-cafe] Hackage and version control >To: haskell-cafe(a)haskell.org >Message-ID: <20090720042525.3e02b4ae@fedora> >Content-Type: text/plain; charset=UTF-8 > >On Mon, 20 Jul 2009 10:03:56 +0100 >Magnus Therning <magnus(a)therning.org> wrote: > >> On Mon, Jul 20, 2009 at 9:26 AM, Vasili I. >> Galchin<vigalchin(a)gmail.com> wrote: >> > Hello, >> > >> > Â Â Â Â It seems to me that Hackage doesn't provide version control, >> > e.g. check out and check in. Am I incorrect? >> >> Hackage is, AFAIU, a repository where _released_ versions of >> libraries/tools/etc related to Haskell can be kept. It is not fully >> comparable to SourceForge, Github, or any other _source hosting_ >> service. >> >> If you are looking for source hosting then take a look at SF, Github, >> Google Code, or something like that. Then upload _released_ versions >> to Hackage. IIRC there is also the possibility of having a Darcs repo >> on community.haskell.org. > >Yes, and darcs repos can also be hosted on patch-tag.com. >community.haskell.org requires you to wait for a volunteer to review >every new project request. Although, you don't need to make a >project request if you only want a 1-developer repository. And by the >way, it only hosts Haskell-related projects, not arbitrary darcs >repositories. > >patch-tag.com doesn't have those constraints. >-- >Robin > > >------------------------------ > >Message: 8 >Date: Mon, 20 Jul 2009 13:41:40 +0400 >From: Miguel Mitrofanov <miguelimo38(a)yandex.ru> >Subject: Re: [Haskell-cafe] Hackage and version control >To: Bulat Ziganshin <Bulat.Ziganshin(a)gmail.com> >Cc: "Vasili I. Galchin" <vigalchin(a)gmail.com>, > haskell-cafe(a)haskell.org >Message-ID: <A8F1BE77-CDC2-4800-9072-78B446CDF84E(a)yandex.ru> >Content-Type: text/plain; charset=US-ASCII; format=flowed > >Or patch-tag.com > >On 20 Jul 2009, at 13:27, Bulat Ziganshin wrote: > >> Hello Vasili, >> >> Monday, July 20, 2009, 12:26:52 PM, you wrote: >> >>> It seems to me that Hackage doesn't provide version control, >>> e.g. check out and check in. Am I incorrect? >> >> i recommend you to use either codeplex or code.google >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > >------------------------------ > >Message: 9 >Date: Mon, 20 Jul 2009 06:36:28 -0400 >From: Joe Fredette <jfredett(a)gmail.com> >Subject: Re: [Haskell-cafe] Hackage and version control >To: Bulat Ziganshin <Bulat.Ziganshin(a)gmail.com> >Cc: "Vasili I. Galchin" <vigalchin(a)gmail.com>, > haskell-cafe(a)haskell.org >Message-ID: <4A6448AC.6060202(a)gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Don't forget about Patch-tag! > >Bulat Ziganshin wrote: >> Hello Vasili, >> >> Monday, July 20, 2009, 12:26:52 PM, you wrote: >> >> >>> It seems to me that Hackage doesn't provide version control, >>> e.g. check out and check in. Am I incorrect? >>> >> >> i recommend you to use either codeplex or code.google >> >> >> >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: jfredett.vcf >Type: text/x-vcard >Size: 296 bytes >Desc: not available >Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090720/42d7f039… > >------------------------------ > >Message: 10 >Date: Mon, 20 Jul 2009 12:40:14 +0200 >From: Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> >Subject: Re: [Haskell-cafe] Hackage and version control >To: haskell-cafe(a)haskell.org >Message-ID: <200907201240.14760.g9ks157k(a)acme.softbase.org> >Content-Type: text/plain; charset="utf-8" > >Am Montag, 20. Juli 2009 05:25 schrieb Robin Green: >> community.haskell.org requires you to wait for a volunteer to review >> every new project request. > >However, response times are usually low. > >Best wishes, >Wolfgang > > >------------------------------ > >Message: 11 >Date: Mon, 20 Jul 2009 14:41:25 +0400 >From: Bulat Ziganshin <bulat.ziganshin(a)gmail.com> >Subject: Re[2]: [Haskell-cafe] Hackage and version control >To: Joe Fredette <jfredett(a)gmail.com> >Cc: "Vasili I. Galchin" <vigalchin(a)gmail.com>, Bulat Ziganshin > <Bulat.Ziganshin(a)gmail.com>, haskell-cafe(a)haskell.org >Message-ID: <121430820.20090720144125(a)gmail.com> >Content-Type: text/plain; charset=us-ascii > >Hello Joe, > >Monday, July 20, 2009, 2:36:28 PM, you wrote: > >afaik it provides minimal features, only VCS, while sitea i mentioned >provides full service for OSS developer > >> Don't forget about Patch-tag! > >> Bulat Ziganshin wrote: >>> Hello Vasili, >>> >>> Monday, July 20, 2009, 12:26:52 PM, you wrote: >>> >>> >>>> It seems to me that Hackage doesn't provide version control, >>>> e.g. check out and check in. Am I incorrect? >>>> >>> >>> i recommend you to use either codeplex or code.google >>> >>> >>> > > > >-- >Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > > >------------------------------ > >Message: 12 >Date: Mon, 20 Jul 2009 06:09:50 +0100 >From: Robin Green <greenrd(a)greenrd.org> >Subject: Re: [Haskell-cafe] ANN: cautious-file 0.1.1: Ways to write a > file cautiously, to avoid data loss >To: haskell-cafe(a)haskell.org >Message-ID: <20090720060950.076176fa@fedora> >Content-Type: text/plain; charset=US-ASCII > >I've since uploaded two new versions with the following changes: > >0.1.2: Fixed an issue where it would clobber symbolic links to files, >which is usually not what you want. Test case added for this. > >0.1.3: ByteString support! FFI is also now used under the hood to do >things in a slightly less hacky way. > >-- >Robin > >On Sun, 19 Jul 2009 23:35:34 +0100 >Robin Green <greenrd(a)greenrd.org> wrote: > >> I'm pleased to announce the first public release of cautious-file: >> >> http://hackage.haskell.org/package/cautious-file ><snip> > > >------------------------------ > >Message: 13 >Date: Mon, 20 Jul 2009 13:27:57 +0200 >From: Roel van Dijk <vandijk.roel(a)gmail.com> >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: haskell-cafe <haskell-cafe(a)haskell.org> >Message-ID: > <ab9dc6fa0907200427g27ef73a1vd5b852187e6b9745(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >I think the tuple sections are a great idea! It also makes tuple types >and constructors more alike: > >x :: (,) String Double >x = (,) "Pi" 3.14159 > >I can also see some uses in writing pointfree code. I would definitely >want this in a future GHC (or any other Haskell compiler/interpreter) >release. > >I'm not so sure about the list comprehension concatenation. Like >Thomas Schilling wrote, it is only a bit shorter then writing it with >the current syntax. So I'm not sure if it is worth the cost. > > >------------------------------ > >Message: 14 >Date: Mon, 20 Jul 2009 09:02:54 -0300 >From: Felipe Lessa <felipe.lessa(a)gmail.com> >Subject: Re: [Haskell-cafe] ANN: cautious-file 0.1.1: Ways to write a > file cautiously, to avoid data loss >To: haskell-cafe(a)haskell.org >Message-ID: <20090720120254.GA6396(a)kira.casa> >Content-Type: text/plain; charset=us-ascii > >Nice library! > >On Sun, Jul 19, 2009 at 11:35:34PM +0100, Robin Green wrote: >> A variant, writeFileWithBackup, also allows you to supply a custom >> backup computation to backup old copy(ies) of the destination file > >It would be nice to have the backup action receive the file name >as a parameter, so it would be possible to have a library of >possible backup strategies. :) > >-- >Felipe. > > >------------------------------ > >Message: 15 >Date: Mon, 20 Jul 2009 13:16:03 +0100 >From: Andy Gimblett <haskell(a)gimbo.org.uk> >Subject: [Haskell-cafe] Typeclass default implementation in subclasses >To: haskell-cafe(a)haskell.org >Message-ID: <5A40667D-984C-4F0A-A7E3-F21980B60CE9(a)gimbo.org.uk> >Content-Type: text/plain; charset=US-ASCII; format=flowed > >Hi all, > >This email is literate Haskell. I have a question about default >implementations of typeclasses. > > > {-# LANGUAGE TypeSynonymInstances #-} > > > module Thing where > > > import Text.PrettyPrint.HughesPJ > >Let say I want to pretty-print some values, enclosed in double quotes. >The natural thing to do (within the HughesPJ pretty-printing >framework, anyway - and that's where I am in this problem's wider >context) is: > > > ppQuote :: Show a => a -> Doc > > ppQuote = doubleQuotes . text . show > >Now, this works nicely for (say) Int: > > > x :: Int > > x = 1 > >*Thing> ppQuote x >"1" > >But less nicely for String and Char, because their Show instances >already insert double/single quotes respectively: > > > y :: String > > y = "hello" > > z :: Char > > z = 'a' > >*Thing> ppQuote y >""hello"" >*Thing> ppQuote z >"'a'" > >I don't want this. I'd like them to be "hello" and "a" respectively. > >So I thought I'd create a typeclass, whose default implementation is >as above... > > > class (Show a) => Quotable a where > > quote :: a -> Doc > > quote = ppQuote > >... but with specialised instances for String and Char (the former >seems to need the TypeSynonymInstances extension?): > > > instance Quotable String where > > quote = text . show -- don't need the doubleQuotes call for String > > instance Quotable Char where > > quote c = quote [c] -- just lift it to String > >Unfortunately, while this works great for String and Char... > >*Thing> quote y >"hello" >*Thing> quote z >"a" > >... the "default implementation" mechanism doesn't work as I'd >expect/hope: > >*Thing> quote x > ><interactive>:1:0: > No instance for (Quotable Int) > arising from a use of `quote' at <interactive>:1:0-6 > Possible fix: add an instance declaration for (Quotable Int) > In the expression: quote x > In the definition of `it': it = quote x > >What I would _like_ would be for the compiler to say "OK, the Quotable >class depends on the Show class, and Int is an instance of Show so Int >is also an instance of Quotable, having the default implementation >(since there isn't a specialised one for it)" - but clearly it >doesn't. > >Please can someone tell me why this doesn't happen, and if there is a >way of making it happen? Also, if there's a more sensible way of >attacking this whole problem, I'd be curious to hear it. > >I should perhaps add that this isn't a huge problem for me, because my >instances will in practice tend to be String and Char anyway, and one >can of course add Quotable instances for anything else easily enough - >but I'm curious now I've come this far. :-) > >Many thanks! > >-Andy > > > >------------------------------ > >Message: 16 >Date: Mon, 20 Jul 2009 09:30:24 -0300 >From: Rafael Gustavo da Cunha Pereira Pinto > <RafaelGCPP.Linux(a)gmail.com> >Subject: [Haskell-cafe] ICFP contest write-up >To: Haskell Caf? <haskell-cafe(a)haskell.org> >Message-ID: > <351ff25e0907200530s2c998777g482bd7674ad5d85a(a)mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >For all Portuguese reading haskellers, I am describing my ICFP 2009 contest >write-up on my blog. Feel free to comment. > >http://rafaelgcpp.blogspot.com/search/label/ICFP2009 > > >For the non-Portuguese readers, Google translation tools do a lousy job, but >it is still readable. > >Regards > >Rafael Gustavo da Cunha Pereira Pinto >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090720/30061e23… > >------------------------------ > >Message: 17 >Date: Mon, 20 Jul 2009 22:09:09 +0930 >From: Reiner Pope <reiner.pope(a)gmail.com> >Subject: [Haskell-cafe] SpecConstr difficulties >To: Haskell Cafe mailing list <haskell-cafe(a)haskell.org> >Message-ID: > <4cf038ee0907200539w1676a6e7ub29350cf5025b91a(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >Hi everyone, > >I've been having some trouble getting SpecConstr to work as I want it >to. The following example (see end of email) came up in some code I >was playing around with. The loops g1 and g2 both compute the same >thing: the maximum element of the "list" (which has been fused away) >of numbers from 1 to 10. > >Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as >an accumulator. The Maybe gets filled after the first element is seen, >so the Maybe is a Just for almost the entire running of the loop. > >It would be good to have this recognised by SpecConstr, to create an >optimised loop for the Just case. This does indeed happen for g1, but >not for g2. > >My difficulty is that I am only able to produce code similar to g2, >i.e. where the pattern matching is in a separate function, 'expose', >because the 'expose' function is implemented in a type-class, like in >stream-fusion. Is there some way to keep the SpecConstr while leaving >the 'expose' as a separate function? > >Here is the code: > >> {-# LANGUAGE BangPatterns #-} >> >> module Test(ans1,ans2) where >> >> import Prelude hiding(Maybe(..)) >> >> data Maybe a = Just !a | Nothing >> >> Nothing `mapp` Just b = Just b >> Just a `mapp` Just b = Just (max a b) >> >> ans1 = g1 Nothing (0::Int) >> >> g1 m !n = case m of >> Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) >> Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) >> >> ans2 = g2 Nothing (0::Int) >> >> g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) >> expose Nothing b = b >> expose (Just a) b = a `seq` b > >On a similar note, when I was having difficulties with this problem, I >started to wonder if it would be possible to come up with a more >direct way to tell GHC, "do SpecConstr on this variable". From reading >the source code of the stream-fusion package, it seems that the >current way of doing this is with 'expose' functions like I wrote >below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used >on function arguments, like: > >foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... > >This pragma should say to the GHC something like "ignore conditions >H2, H5 and H6 of the SpecConstr paper, for this function and this >argument". > >Cheers, >Reiner > > >------------------------------ > >Message: 18 >Date: Mon, 20 Jul 2009 14:40:26 +0200 >From: Roel van Dijk <vandijk.roel(a)gmail.com> >Subject: Re: [Haskell-cafe] Typeclass default implementation in > subclasses >To: Andy Gimblett <haskell(a)gimbo.org.uk> >Cc: haskell-cafe(a)haskell.org >Message-ID: > <ab9dc6fa0907200540s211a67bby6107c556bb42f171(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >This post is also literate haskell. By enabling these potentially >dangerous extensions you'll get the behaviour you want. > >> {-# LANGUAGE TypeSynonymInstances #-} >> {-# LANGUAGE UndecidableInstances #-} >> {-# LANGUAGE FlexibleInstances #-} >> {-# LANGUAGE OverlappingInstances #-} > >> module Thing where > >> import Text.PrettyPrint.HughesPJ > >> ppQuote :: Show a => a -> Doc >> ppQuote = doubleQuotes . text . show > >> x :: Int >> x = 1 > >> y :: String >> y = "hello" >> z :: Char >> z = 'a' > >> class (Show a) => Quotable a where >> quote :: a -> Doc >> quote = ppQuote > >> instance (Show a) => Quotable a > >> instance Quotable String where >> quote = text . show -- don't need the doubleQuotes call for String > >> instance Quotable Char where >> quote c = quote [c] -- just lift it to String > >Example: > >*Thing> quote "pi" >"pi" >*Thing> quote 3.14159 >"3.14159" > > >------------------------------ > >Message: 19 >Date: Mon, 20 Jul 2009 23:08:49 +1000 >From: Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> >Subject: [Haskell-cafe] ANNOUNCE: graphviz-2999.1.0.1 >To: haskell(a)haskell.org >Cc: haskell-cafe(a)haskell.org >Message-ID: <87vdlnwlge.fsf(a)gmail.com> >Content-Type: text/plain; charset=us-ascii > >This is a bug-fix release to fix the various Attribute-related problems >in the previous release (2999.0.0.0) spotted mainly by Zsolt >Dollenstein. Please disregard version 2999.1.0.0; it had a small bug. >Similarly, people should avoid using 2999.0.0.0 unless they don't use >any Either-based Attributes. > >The problem (which took me a while to realise) was that whilst I was >using Either to denote that an attribute could take one of two different >types of values (e.g. Bool and String) and the parsing for that worked. >However, since I was using Show (I know it's bad, it was on my TODO, >remember?) to generate the Dot code, then whenever one of these values >was converted then either Left or Right would appear, and GraphViz >doesn't seem to like that for some reason... > >I also took the opportunity to define custom types for more Attributes >(as they only accept certain String values). Furthermore, GraphViz >states that attributes that can accept a boolean value are set to True >when the attribute is listed on its own; the library now does this even >for those Attributes that use a custom type that combines Bool with >something else. One other small change is that the Color Attribute now >takes in a list of Colors; if you only want one, use a singleton list >(it was either that or a custom datatype that takes either a single >Color or a list of Colors...). > >Note that 2999.1.0.0 accidentally only had singleton Color values for >the Color Attribute rather than a list, hence the quick version bump. > >Nothing else has changed in the library apart from the Attributes. > >Regarding my request in the previous email about the possible new layout >of the DotGraph datatype: > >How many people actually build DotGraphs by hand or pull them apart by >hand? If there were getNodes :: DotGraph -> [Node] and getEdges :: >DotGraph -> [Edge] functions available, would you accept an all-in-one >data type that just contains a generic list of statements and thus >follows upstream more closely? Even leaving aside parsing, this would >allow for greater flexibility for creating wild and wacky graphs or for >a monadic interface or something for building DotGraphs (which someone >has asked me for, but which at the moment I have no idea how to do...). > >-- >Ivan Lazar Miljenovic >Ivan.Miljenovic(a)gmail.com >IvanMiljenovic.wordpress.com > > >------------------------------ > >Message: 20 >Date: Mon, 20 Jul 2009 15:22:24 +0200 >From: Roel van Dijk <vandijk.roel(a)gmail.com> >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: haskell-cafe <haskell-cafe(a)haskell.org> >Message-ID: > <ab9dc6fa0907200622h1b76481ctd7f13d65d1282261(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On Mon, Jul 20, 2009 at 1:27 PM, Roel van Dijk<vandijk.roel(a)gmail.com> wrote: >> I think the tuple sections are a great idea! It also makes tuple types >> and constructors more alike: >> >> x :: (,) String Double >> x = (,) "Pi" 3.14159 > >I just realised this is already in GHC :-) But does you patch also add >the equivalent for tuple type annotations? > >x :: (String, ) Double >x = ("Pi", ) 3.14159 > >I am also wondering what the following would/should mean: > > (1, , ( , 2), ) 'a' 'b' 'c' > >Should this mean > (1, 'a', ('b', 2), 'c') >or > (1, 'a', ('c', 2), 'b') > >Intuitively I would expect the first option. Just reading from left to >right. But it doesn't look entirely trivial. > > >------------------------------ > >Message: 21 >Date: Mon, 20 Jul 2009 14:25:56 +0100 >From: "Sittampalam, Ganesh" <ganesh.sittampalam(a)credit-suisse.com> >Subject: RE: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: "haskell-cafe" <haskell-cafe(a)haskell.org> >Message-ID: > <16442B752A06A74AB4D9F9A5FF076E4B03B9F7DC(a)ELON17P32001A.csfb.cs-group.com> > >Content-Type: text/plain; charset=us-ascii > >Roel van Dijk wrote: >> On Mon, Jul 20, 2009 at 1:27 PM, Roel van >> Dijk<vandijk.roel(a)gmail.com> wrote: >>> I think the tuple sections are a great idea! It also makes tuple >>> types and constructors more alike: >>> >>> x :: (,) String Double >>> x = (,) "Pi" 3.14159 >> >> I just realised this is already in GHC :-) But does you patch also >> add the equivalent for tuple type annotations? >> >> x :: (String, ) Double >> x = ("Pi", ) 3.14159 >> >> I am also wondering what the following would/should mean: >> >> (1, , ( , 2), ) 'a' 'b' 'c' > >I would expect it to be a type error, since I think the following is the >only sane type the tuple can have (assuming numeric literals :: Int): > >(1, , ( , 2), ) :: a -> b -> (Int, a, c -> (c, Int), b) > >Ganesh > >=============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > =============================================================================== > > > >------------------------------ > >Message: 22 >Date: Mon, 20 Jul 2009 15:42:08 +0200 >From: Roel van Dijk <vandijk.roel(a)gmail.com> >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: "Sittampalam, Ganesh" <ganesh.sittampalam(a)credit-suisse.com> >Cc: haskell-cafe <haskell-cafe(a)haskell.org> >Message-ID: > <ab9dc6fa0907200642u678cfe2ep22ffeef3308927eb(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >>> I am also wondering what the following would/should mean: >>> >>> (1, , ( , 2), ) 'a' 'b' 'c' >> >> I would expect it to be a type error, since I think the following is the >> only sane type the tuple can have (assuming numeric literals :: Int): >> >> (1, , ( , 2), ) :: a -> b -> (Int, a, c -> (c, Int), b) >> >> Ganesh > >Ah you're completely right! I would be applying a tuple to a Char >which is nonsense. > > >------------------------------ > >Message: 23 >Date: Mon, 20 Jul 2009 07:02:22 -0700 >From: Jason Dagit <dagit(a)codersbase.com> >Subject: Re: [Haskell-cafe] FFI problem - possibility of CStringLen > overflow? >To: Robin Green <greenrd(a)greenrd.org> >Cc: haskell-cafe(a)haskell.org >Message-ID: > <b97f58860907200702s769b48cao85d5d5c2f15f183e(a)mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >On Sun, Jul 19, 2009 at 7:24 PM, Robin Green <greenrd(a)greenrd.org> wrote: > >> While rewriting cautious-file to use ByteStrings and FFI just now, I >> came across this potential problem: >> >> Why does the FFI specification define CStringLen as (Ptr CChar, Int)? > > >Do you think it was a typo and the author(s) meant (Ptr CChar, CInt) ? > >Jason >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090720/abed0080… > >------------------------------ > >Message: 24 >Date: Mon, 20 Jul 2009 15:07:23 +0100 >From: Philippa Cowderoy <flippa(a)flippac.org> >Subject: [Haskell-cafe] Anglohaskell - wifi signups >To: haskell(a)haskell.org, Haskell cafe <haskell-cafe(a)haskell.org> >Message-ID: <4A647A1B.7010408(a)flippac.org> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Wifi signups are Anglohaskell are now on the wiki - please add your >details by the 31st of July if you want a wifi account at MS Research >for the Friday. Alternatively, reply to this email with your full name, >institution, country of residence and email address. > >The Anglohaskell wiki page can be found at >http://www.haskell.org/haskellwiki/AngloHaskell/2009 > >There's still room for more talks if anyone's got something they fancy >giving a go - everything from cutting edge research to "what I did with >Haskell on my holiday" is welcome, as is everyone from GHC implentors to >newbies frantically writing Hello World on their laptop in the back row. > >-- >flippa(a)flippac.org > > >------------------------------ > >Message: 25 >Date: Mon, 20 Jul 2009 11:09:40 -0700 >From: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> >Subject: [Haskell-cafe] Pruning the Front Page >To: haskell mailing list <haskell-cafe(a)haskell.org> >Message-ID: > <4c44d90b0907201109v75f5427ra5aadefdf1722663(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >All, >I think we should remove unmaintained or refocused implementations >from the haskell.org front page. This would mean removing: > YHC - unmaintained, hasn't built for me in a while > LHC - Not a standalone compiler these days - perhaps should be >linked as a GHC subproject? > >Other than those I'd propose NHC but I'm guessing that would get some >pushback (even though it currently doesn't build for me). Before >anyone brings up HUGS I'll just say that 1) it is used 2) it builds 3) >at least it's been updated more recently than the Haskell langauge. > >Thomas > > >------------------------------ > >Message: 26 >Date: Mon, 20 Jul 2009 11:12:16 -0700 >From: Don Stewart <dons(a)galois.com> >Subject: Re: [Haskell-cafe] Pruning the Front Page >To: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> >Cc: haskell mailing list <haskell-cafe(a)haskell.org> >Message-ID: <20090720181216.GL15846(a)whirlpool.galois.com> >Content-Type: text/plain; charset=us-ascii > >thomas.dubuisson: >> All, >> I think we should remove unmaintained or refocused implementations >> from the haskell.org front page. This would mean removing: >> YHC - unmaintained, hasn't built for me in a while >> LHC - Not a standalone compiler these days - perhaps should be >> linked as a GHC subproject? >> >> Other than those I'd propose NHC but I'm guessing that would get some >> pushback (even though it currently doesn't build for me). Before >> anyone brings up HUGS I'll just say that 1) it is used 2) it builds 3) >> at least it's been updated more recently than the Haskell langauge. >> > >I guess we just acknowledge that all implementations are not equal, and >for newbies we strongly recommend GHC + Haskell Platform. For >reference, we point to a page listing all implementations. > >This follows convention (i.e. Python, Ruby only point to the canonical >impls, not the various forks). > >-- Don > > >------------------------------ > >Message: 27 >Date: Mon, 20 Jul 2009 20:14:30 +0100 >From: Max Bolingbroke <batterseapower(a)hotmail.com> >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: Roel van Dijk <vandijk.roel(a)gmail.com> >Cc: haskell-cafe <haskell-cafe(a)haskell.org> >Message-ID: > <9d4d38820907201214n79cc48a8jc5e5f19af511129d(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >2009/7/20 Roel van Dijk <vandijk.roel(a)gmail.com>: >> I just realised this is already in GHC :-) But does you patch also add >> the equivalent for tuple type annotations? >> >> x :: (String, ) Double >> x = ("Pi", ) 3.14159 > >It doesn't, and indeed it would only work in the special case where >your only missing type arguments are on the right (since we lack >type-level lambda, we can only accept eta-reduced forms). So it >probably wouldn't be worth it - it wouldn't allow you to write >anything significantly shorter than the existing form "(,) String". > >Cheers, >Max > > >------------------------------ > >Message: 28 >Date: Mon, 20 Jul 2009 21:26:05 +0100 >From: phil(a)beadling.co.uk >Subject: Re: [Haskell-cafe] Ambiguous type variable - help! >To: gale(a)sefer.org >Cc: haskell-cafe(a)haskell.org >Message-ID: <47ED22E9-0828-4B19-A182-6F69DE919CC4(a)beadling.co.uk> >Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > >On 19 Jul 2009, at 21:18, Yitzchak Gale wrote: > >> Hi Phil, > >> >> >>> I've concocted a very simple example to illustrate this (below) - but >>> it doesn't compile because ghc complains that my type is ambiguous >>> arising >>> from my use of 'fromSeq'. >> >> Notice that you have given two completely separate sets >> of instructions of what to do depending on whether Int >> or Double is selected. You have not given any indication >> of how to choose between them, even at runtime. Of course, >> the compiler doesn't care that your string constants "Int" and >> "Double" happen also to be the names of types if unquoted. > >I see now. I'm passing fromSeq a SeqType, but it has no way >of knowing if I want to process it as an Int or a Double. >The only thing which is polymorphic is nextSeq as it must handle >the underlying state of Int and Double. > >Your result function handles the general case and the typeclass >instances deal with the specialization depending on the state's type. > >The printResult function takes in a SeqType and then "parses" (for >want of >a better word) out the >underlying type of Int or Double. It then calls results against the >Int or Double which >in turn will invoke the correct version of nextSeq. > > >Thank you very much for explaining this! > > >Phil. > >> >> import Control.Monad.State -- Why Strict? Haskell is lazy by default. >> > >Ahh, no reason for the Strict - in the large program I'm righting it >is required >because otherwise I end up with almighty thunks. But here it serves >no purpose. > > > >------------------------------ > >Message: 29 >Date: Mon, 20 Jul 2009 22:25:30 +0200 >From: Nicolas Pouillard <nicolas.pouillard(a)gmail.com> >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: Max Bolingbroke <batterseapower(a)hotmail.com> >Cc: haskell-cafe <haskell-cafe(a)haskell.org> >Message-ID: <1248121473-sup-8534(a)ausone.local> >Content-Type: text/plain; charset=UTF-8 > >Excerpts from Max Bolingbroke's message of Sun Jul 19 16:58:08 +0200 2009: >> Dear Cafe, >> >> For fun, I spent a few hours yesterday implement support for this >> syntax in GHC, originally propsed by Koen Claessen: >> > >[...] > >> P.S. I also implemented tuple sections >> (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are >> a lot more useful: > >I vote for both extensions. > >-- >Nicolas Pouillard >http://nicolaspouillard.fr > > >------------------------------ > >Message: 30 >Date: Tue, 21 Jul 2009 13:36:04 +1200 (NZST) >From: porges(a)porg.es >Subject: Re: [Haskell-cafe] Implicit concatenation in list > comprehensions >To: Roel van Dijk <vandijk.roel(a)gmail.com> >Cc: haskell-cafe <haskell-cafe(a)haskell.org>, "Sittampalam, Ganesh" > <ganesh.sittampalam(a)credit-suisse.com> >Message-ID: <fxdyfegnp48plbb647UYAxe124vaj_firegpg(a)mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >2009/7/21 Roel van Dijk <vandijk.roel(a)gmail.com>: >>>> I am also wondering what the following would/should mean: >>>> >>>> Â (1, , ( , 2), ) 'a' 'b' 'c' >>> >>> I would expect it to be a type error, since I think the following is the >>> only sane type the tuple can have (assuming numeric literals :: Int): >>> >>> (1, , ( , 2), ) :: a -> b -> (Int, a, c -> (c, Int), b) >>> >>> Ganesh >> >> Ah you're completely right! I would be applying a tuple to a Char >> which is nonsense. > >You can kind of do it if you indicate which 'field' is to be applied: > > import Control.Applicative > > newtype Fst b a = Fst (a,b) deriving (Show) > newtype Snd a b = Snd (a,b) deriving (Show) > > instance Functor (Fst b) where > fmap f (Fst (a,b)) = Fst (f a,b) > > instance Functor (Snd a) where > fmap f (Snd (a,b)) = Snd (a,f b) > > f <$$> x = ($x) <$> f > >... > >> Fst ((,)1,3) <$$> 2 -- no section, don't have the patch ;) >Fst ((1,2),3) >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: signature.asc >Type: application/pgp-signature >Size: 908 bytes >Desc: OpenPGP digital signature >Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090720/914e9c57… > >------------------------------ > >Message: 31 >Date: Mon, 20 Jul 2009 22:02:00 -0400 >From: Gwern Branwen <gwern0(a)gmail.com> >Subject: Re: [Haskell-cafe] Pruning the Front Page >To: Thomas DuBuisson <thomas.dubuisson(a)gmail.com> >Cc: haskell mailing list <haskell-cafe(a)haskell.org> >Message-ID: > <cbf55b100907201902h4fda9be9jc0cc333cf4ddaa42(a)mail.gmail.com> >Content-Type: text/plain; charset=UTF-8 > >On Mon, Jul 20, 2009 at 2:09 PM, Thomas >DuBuisson<thomas.dubuisson(a)gmail.com> wrote: >> All, >> I think we should remove unmaintained or refocused implementations >> from the haskell.org front page. Â This would mean removing: >> Â Â YHC - unmaintained, hasn't built for me in a while >> Â Â LHC - Not a standalone compiler these days - perhaps should be >> linked as a GHC subproject? >> >> Other than those I'd propose NHC but I'm guessing that would get some >> pushback (even though it currently doesn't build for me). Â Before >> anyone brings up HUGS I'll just say that 1) it is used 2) it builds 3) >> at least it's been updated more recently than the Haskell langauge. >> >> Thomas > >What about UHC and JHC? They're both maintained (in their varying >degrees), but I don't think they can do anything but pure Haskell >'98*, and I dunno whether they could even compile the Cabal packages >which are/depend only on Haskell '98. > >What should our criterion be? Just maintained? Maintained and at least >able to compile Haskell '98 source? Maintained, able to compile >Haskell '98, and also the pure Haskell '98 subset of Hackage? > >I prefer the last triplet since it's the best for newbies and the >minimum necessary for practicality beyond rolling everything oneself, >but perhaps that's too strict for everyone else. > >* by which I mean Haskell '98, the FFI, and hierarchical modules > >-- >gwern > > >------------------------------ > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe > > >End of Haskell-Cafe Digest, Vol 71, Issue 30 >********************************************

2 2

ANN: Leksah 0.6
by Hamish Mackenzie 24 Jul '09

24 Jul '09

Hi, Just a quick note to let people know we released a new version of Leksah this week. Thanks for the help and feedback on the previous version. We have done our best to add the features we thought were most pressing. Please give it a go and let us know what features you would like to see most in the future. http://leksah.org/ __ What's New __ * Integrated GHCi based debugging * Multi-window support (View -> Detach) * Improved layout control (drag & drop and nesting) * Regular expression find and replace * Grep files in the current package * Improved Mac OS X integration __ Known Bugs and Problems __ * The package editor works only for cabal files without configurations. * MS Windows: The check for external modifications of source files does not work. * MS Windows: Interruption of a background build does not work. * Navigation in Trace history does not work. Mac OSX users can install using Mac Ports as usual or use the provided Intel binary (tested on Leopard only). http://leksah.org/Leksah-0.6.1.0.dmg Hamish

5 11

QuickCheck behaving strange
by Tobias Olausson 24 Jul '09

24 Jul '09

Hey Guys! I was writing a small implementation of the earliest-end-first algorithm for the Interval Scheduling problem just now. When I was done, I thought it would be a nice thing to have a QuickCheck property for my code. This is what I came up with: -- Intervals are just triplets type Interval a t = (a,t,t) end :: Interval a t -> t end (_,_,t) = t begin :: Interval a t -> t begin (_,t,_) = t And so the property: prop_schedule :: Ord t => [Interval a t] -> Bool prop_schedule [] = True prop_schedule [a] = True prop_schedule (x:y:ys) = end x <= begin y && prop_schedule (y:ys) Essentially, it looks up wheather the given list is "sorted" (given the constraints of the problem). However, in this property I forgot to add that the lists should have been run through my algorithm, which I noticed only after this strange problem appeared: *Interval> quickCheck prop_schedule +++ OK, passed 100 tests. How come QuickCheck passes 100 tests of random lists? One would think that at least one of the generated lists would be unsorted. It also passes 1000 and even 10000 tests. It also seems that changing the type helps: prop_schedule :: [Interval a Int] -> Bool ... *Interval> quickCheck prop_schedule *** Failed! Falsifiable (after 5 tests and 1 shrink): [((),0,0),((),-1,0)] -- Tobias Olausson tobsan(a)gmail.com

4 4

Re: [Haskell] ANN: yices 0.0.0.1 - Haskell programming interface to Yices SMT solver
by Aaron Tomb 24 Jul '09

24 Jul '09

You may want to take a look at this, as well: http://www.sivity.net/projects/smt-yices Aaron On Jul 23, 2009, at 5:32 PM, Ahn, Ki Yung wrote: > http://hackage.haskell.org/package/yices > > Incomplete (no bitvectors) syntax, parser, and inter > process communication to Yices from Haskell through pipe. > Purpose for building and using this library was to generate > test cases from constraints that SMT solvers can solve. I > only used it for that particular purpose, so the code in > general is not yet fully tested. Use at your own risk and > error reports are welcomed. See http://yices.csl.sri.com/ > for further information on Yices. > > Note: this package does not include Yices. You should get it from the > Yices homepage and install it before using this library. > > @ If you already have a better API for Yices or other SMT solvers, and > if you can open the source please upload it to hacakage. That would > be > great help for some people. > > -- > Ahn, Ki Yung > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- Aaron Tomb Galois, Inc. (http://www.galois.com) atomb(a)galois.com Phone: (503) 626-6616 ext. 156 Fax: (503) 350-0833

1 0

ANN: darcs 2.3.0
by Petr Rockai 24 Jul '09

24 Jul '09

Hello! I'd like to announce immediate availability of a new stable release of darcs, 2.3.0. There is a number of improvements and bugfixes over the previous stable release, 2.2. Moreover, work has been done to improve performance of "darcs whatsnew" for large repositories. As in the past, there are two source tarballs available. As of this release, the cabal-based build is preferred, and the autoconf build is deprecated. You can obtain the source tarballs at these addresses: * http://repos.mornfall.net/darcs/darcs-2.3.0.tar.gz * http://repos.mornfall.net/darcs/darcs-2.3.0_autoconf.tar.gz The build instructions are available in the enclosed README file in those tarballs. Moreover, if you have cabal-install available, you can install latest stable release of darcs by issuing the following commands (no tarballs needed): $ cabal update $ cabal install darcs This should give you a darcs binary in `~/.cabal/bin` -- you should probably add this to your PATH. More detailed instructions for installing on Windows are available near the end of this announcement. What's New ---------- This is a summary of important changes since the last stable release (2.2): * Lots and lots of documentation changes (Trent). * Haskeline improvements (Judah). * Cabal as default buildsystem (many contributors). * Fixes in darcs check/repair memory usage (Bertram, David). * Performance improvement in subtree record (Reinier). * New option: --summary --xml (Florian Gilcher). * New option: changes --max-count (Eric and Petr). * Fix changes --only-to-files for renames (Dmitry). * Performance fix in "darcs changes" (Benedikt). * Hardlinks on NTFS (Salvatore). * Coalesce more changes when creating rollbacks (David). * New unit test runner (Reinier). * Inclusion of darcs-shell in contrib (László, Trent). * Author name/address canonisation: .authorspellings (Simon). * Working directory index and substantial "darcs wh" optimisation (Petr). * New command: "darcs show index" (Petr). * Gzip CRC check and repair feature (Ganesh). A number of issues has been resolved since 2.2 as well. See http://bugs.darcs.net/issueN for details on bug number N. * 948 darcsman (Trent) * 1206 countable nouns (Trent) * 1285 cabal test v. cabal clean (Trent) * 1302 use resolved, not resolved-in-unstable (Trent) * 1235 obliterate --summary (Rob) * 1270 no MOTD for --xml-output (Lele) * 1311 cover more timezones (Dave) * 1292 re-encoding haskeline input (Judah) * 1313 clickable ToC and refs in PDF manual Trent) * 1310 create merged \darcsCommand{add} (Trent) * 1333 better "cannot push to current repository" warning (Petr) * 1347 (autoconf) check for unsafeMMapFile if mmap use enabled (Dave) * 1361 specify required includes for curl in cabal file (Reinier) * 1379 remove libwww support (Trent) * 1366 remove unreachable code for direct ncurses use (Trent) * 1271 do not install two copies of darcs.pdf (Trent) * 1358 encode non-ASCII characters in mail headers (Reinier) * 1393 swap "darcs mv" and "darcs move" (Trent) * 1405 improve discoverability of global author file (Trent) * 1402 don't "phone home" about bugs (Trent) * 1301 remove obsolete zsh completion scripts (Trent) * 1162 makeAbsolute is now a total function (Ben F) * 1269 setpref predist - exitcode ignored bug (Ben M) * 1415 --edit-long-comment, not --edit-description, in help (Trent) * 1413 remove duplicate documentation (Trent) * 1423 complain about empty add/remove (Trent) * 1437 Implement darcs changes --max-count (Eric) * 1430 lazy pattern matching in (-:-) from Changes command module (Dmitry) * 1434 refactor example test (Trent) * 1432 refer to %APPDATA%, not %USERPROFILE% (Trent) * 1186 give a chance to abort if user did not edit description file (Dmitry) * 1446 make amend-record -m foo replace only the patch name (Dmitry) * 1435 default to get --hashed from a darcs-1.0 source (Trent) * 1312 update and reduce build notes (Trent) * 1351 fix repository path handling on Windows (Salvatore) * 1173 support hard links on NTFS (Salvatore) * 1248 support compressed inventories for darcs-1 repos (Ganesh) * 1455 implement "darcs help environment" (Trent) The question of GHC 6.8 ----------------------- Using GHC 6.10.3 or newer is *strongly recommended*. You may compile darcs with GHC 6.8, but there are several caveats. If you are using 6.8.2 or older, please disable mmap support (pass -f-mmap to cabal install or runghc Setup configure). Note that the GHC 6.8.2 that ships with Debian Lenny is not affected and it should be safe to keep mmap enabled. It is also recommended to disable use of Hackage zlib when compiling with GHC 6.8.2 (including the Debian Lenny version): pass -f-zlib to cabal. When using zlib, we have seen occasional crashes with error messages like "openBinaryFile: file locked" -- this is a known GHC 6.8.2 bug (and is fixed in GHC 6.8.3). Last, if you are using a 64-bit system, darcs may hang when you exit a pager when compiled with GHC older than 6.10.3. Although this is harmless, it is quite inconvenient. Overall, the status of GHC 6.8 is "semi-supported": for many cases, things will work just fine, especially if you take a little extra caution with compilation flags. Installing on Windows --------------------- To install darcs on Windows systems from scratch, please download the Haskell Platform and MSYS: * http://hackage.haskell.org/platform/2009.2.0.1/HaskellPlatform-2009.2.0.1-s… * http://sourceforge.net/projects/mingw/files/MSYS+Base+System/MSYS-1.0.11-rc… After installing both, you should have an "MSYS" icon: run MSYS and in the terminal window type (the `$` character denotes the prompt, do not repeat it): $ cabal update $ cabal install darcs -f-curl This should download, compile and install all required dependencies and also darcs itself. The resulting darcs executable will be placed into the Haskell Platform executables folder, and should be accessible from the MSYS shell (just type "darcs --version" to check). Yours, Petr.

2 2

Static linking
by Michael Oswald 24 Jul '09

24 Jul '09

Hello, I wrote a small installer program which configures and installs some software packages. In order to be able to let it run on a different machine, where I possibly don't have the needed shared libraries, I tried to link it statically, following this advice: http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell#Dep… g_statically_linked_applications However I get some linking errors: ghc --make Installer.hs -static -optl-static /usr/lib/ghc-6.10.3/unix-2.3.2.0/libHSunix-2.3.2.0.a(User__143.o)(.text+0xf1): In function `s7Tu_info': : warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../libedit.a(readline.o)(.text+0x7b 2): In function `username_completion_function': /home/oswald/build/libedit-20090610-3.0/src/readline.c:1467:0: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking src/dlmalloc.c:2486:0: undefined reference to `pthread_mutex_lock' /usr/lib/ghc-6.10.3/libffi.a(closures.o)(.text+0x132):src/dlmalloc.c:2493: undefined reference to `pthread_mutex_unlock' /usr/lib/ghc-6.10.3/libffi.a(closures.o)(.text+0x184):src/dlmalloc.c:2490: undefined reference to `pthread_mutex_init' /usr/lib/ghc-6.10.3/libffi.a(closures.o)(.text+0x227): In function `ffi_closure_free': Because of the undefined references to pthread_mutex_lock I then tried various versions of ghc --make Installer.hs -static -optl-static -lpthread -lrt and reordered the -l switches, but neither combination helped. I always get the same error. Does somebody know how to correctly specify the pthread library for this? lg, Michael

2 2

Don't miss CUFP
by Simon Peyton-Jones 24 Jul '09

24 Jul '09

Hey, guys, This list has zillions of people who use Haskell for day-to-day work. So you might want to come to the now-annual workshop for Commercial Users of Functional Programming (CUFP) http://cufp.galois.com 4 Sept 2009, Edinburgh Speakers from companies including Facebook, Barclays Capital, and EDF Trading, using Haskell, Scala, F#, among others. Better still, CUFP is preceded and followed by a day of developer-focused tutorials: Developer Tracks on Functional Programming http://www.defun2009.info/blog/ 3 and 5 Sept, Edinburgh Tutorials covering tools and libraries in Erlang, OCaml, Scala, PLT Scheme, and more. And if that isn't enough, all this is co-located with International Conference on Functional Programming (ICFP) Haskell Symposium ML Workshop Generic Programming Workshop Erlang Workshop Haskell Implementors Workshop Such a cornucopia of delights. It'll be fun. But you do have to register: http://www.cs.nott.ac.uk/~gmh/icfp09.html Simon

1 0

FFI to double constants, printf
by Maurício 24 Jul '09

24 Jul '09

When we printf doubles from C (like when using hsc2hs to bind to a constant) we can get something that's not valid Haskell. See these 2 examples: 3.40282347e+38F inf Do you know some way to printf a double using printf (or any other standard function) that's always going to give me valid Haskell text, even in special cases? Thanks, Maurício

4 4

Leksah works!
by Eugene Kirpichov 23 Jul '09

23 Jul '09

Hi. Quite a while ago I launched Leksah and couldn't get anything done at all; so I thought it is probably never be completed and abandoned attempts to find an IDE for Haskell. However, 3 days ago I launched the new version and it works fantastic! It has an IntelliSense popup with type annotations, a module browser, build-on-the-fly and other things, even though I used it only for 15 minutes (then the ICFP contest began, where I wrote in Python and Java). Main point: It seems a vastly more convenient IDE for Haskell than vim (don't know about emacs-mode). So, I'd like to encourage haskellers to install it and give it a try :) -- Eugene Kirpichov Web IR developer, market.yandex.ru

7 8

Generalizing takeWhile
by Matthias Görgens 23 Jul '09

23 Jul '09

I need to take some elements from the front of a list. However the criteria are somewhat complex. > walk f [] = [] > walk f (x:xs) = case f x > of Just g -> x : walk g xs > Nothing -> [] For each item the `predicate' f either returns Nothing, when it thinks we should not take any more elements, or return Just another `predicate' to apply to the next element. However the type system does not like my function. How can I mollify it?

7 9

is closing a class this easy?
by Conor McBride 23 Jul '09

23 Jul '09

Friends Is closing a class this easy? -------------------------------------- module Moo ( Public(..) ) where class Private x => Public x where blah :: ... class Private x where instance Private A where instance Public A where blah = ... instance Private B where instance Public B where blah = ... -------------------------------------- Modules importing Moo get Public and its instances, but cannot add new ones: any such instances must be accompanied by Private instances, and Private is out of scope. Does this work? If not, why not? If so, is this well known? It seems to be just what I need for a job I have in mind. I want a class with nothing but hypothetical instances. It seems like I could write -------------------------------------- module Noo ( Public(..) , public ) where class Private x => Public x where blah :: ... blah = ... class Private x where public :: (forall x. Public x => x -> y) -> y public f = f Pike data Pike = Pike instance Private Pike instance Public Pike -------------------------------------- But if I don't tell 'em Pike, I've ensured that blah can only be used in the argument to public. Or is there a hole? Cures youriously Conor

7 13

Mixing C and Haskell code in the same file
by Maurício 23 Jul '09

23 Jul '09

Is it possible to insert C code directly to, say, .hsc files? I see this construct in ghc user docs: #def ... which should insert definitions, but I could not find examples of usage in Hackage. My goal is to write some cpp macros that build both a C function and its 'foreign import ccall' wrapper in the same file. Thanks for your help, Maurício

4 5

ANN: Semantic Web
by Vasili I. Galchin 23 Jul '09

23 Jul '09

I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - GK(a)ninebynine.org: 1) http://www.ninebynine.org/RDFNotes/Swish/Intro.html 2) http://www.ninebynine.org/Software/swish-0.2.1.html I am personally very excited about Graham's work and the role of Haskell in his toolkit! II.) My role I "cabalized" Swish-0.2.1, brought namespace issues up to 6.8.2 standards and fixed many compiler warnings. There are still numerous warnings mostly related to lack of function type signatures. Swish-0.2.1 however does build and the tests that Graham wrote do run ok. Currently Swish-0.2.1 is currently hosted on Hackage but will most likely move to another site in the future. The downloader will find that there are TBDs in the swish.cabal file and other places. Please be patient. Kind regards, Vasili

2 1

Implicit concatenation in list comprehensions
by Max Bolingbroke 22 Jul '09

22 Jul '09

Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: >>> [k, "=", v, " " | (k, v) <- [("foo", "1"), ("bar", "2")] ["foo", "=", "1", " ", "bar", "=", "2", " "] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. One situation where I have found this to be useful is when you are writing Haskell programs that call lots of external programs and you need to set the flags based on some tests, like so: rawSystem "myProgram" $ ["foo" | fooing_enabled] ++ ["bar1", "bar2" | baring_enabled] I have submitted a ticket to GHC HQ with the patch (http://hackage.haskell.org/trac/ghc/ticket/3380#comment:5) but as it is just a small convenience it most likely won't make it in unless there is more demand for the feature. So, now is the time to speak up in favour of (or indeed, against) the added syntax! All the best, Max P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: >>> (, True, "Hello", ) 1 "World" (1, True, "Hello", "World")

16 21

Re: cheap in-repo local branches (just needs implementation)
by Petr Rockai 22 Jul '09

22 Jul '09

Grant Husbands <darcsusers(a)grant.x43.net> writes: > The original note that I should have quoted was from Max Battcher: > : Additionally, there would be other useful management tools > : (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think > : that these four commands could be done with no darcs interaction at all > : (unless the branch being switched to has an incomplete/lazy pristine). Ah, OK. This is mistake on Max's part, since there's no such thing as incomplete/lazy pristine. I.e. this is a non-issue. > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) Well, the problem with that point is that maybe half of your points were trivially untrue, which sort of puts a dent into the argument itself. :) > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. No-one says it is going to be less or more work to do this within or outside of darcs. No doubt, some darcslib usage is quite likely (for patch application and unapplication, eg.). However, it is still relatively manageable, and in a limited form also relatively easy (but that's true of almost anything, the 80/20 rule). > There's also the strong possibility that the system would get mostly > implemented, with a few gotchas here and there and a few incomplete > features, and then there'd less impetus for writing a good, integral > branching system. You are probably overdoing the "integral" part of the equation, given that the only difference is administrative. You can import parts of darcs from outside of darcs just fine, these days. Anyway, the 80/20 problem is equivalently applicable to in-darcs as it is to out-of-darcs implementation. Yours, Petr.

1 0

Re: [darcs-users] cheap in-repo local branches (just needs implementation)
by Eric Kow 22 Jul '09

22 Jul '09

On Wed, Jul 22, 2009 at 16:48:39 +0100, Grant Husbands wrote: > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) I think it's quite useful that you're doing this, thanks. The hope was to solicit discussion, after all! I'd particularly appreciate it if we could summarise any results from this on the bug tracker in the end http://bugs.darcs.net/issue555 > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. Another option to consider: though this may be straying from the idea of implementing a standalone tool, but it seems that darcs-branch could outsource any clever bits to the Darcs library (and that we'd have to think carefully through extensions to the Darcs library and not just hashed-storage to make this work). -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0

Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
by Kalman Noel 22 Jul '09

22 Jul '09

Thomas ten Cate schrieb: > There are two ways of looking at the mod operator (on integers): > > 1. As a map from the integers Z to Z/pZ. > [...] > 2. As the remainder under division by p. > Since n mod 0 would be the remainder under division by 0, this > correctly gives a division by zero error. > > I used to think that the definitions were equivalent... apparently not. They are if you don't disallow division by zero with remainder. Namely, the definition of “division with remainder” works as in (1).

1 0

what about adding a HIDE pragma ?
by Marc Weber 22 Jul '09

22 Jul '09

I know about module Foo ( exportedFuncA, ExportedType(..) ) where exportedFuncA :: .. exportedFuncA = .. data ExportedType = ExportedType It's great that you can only export a subset of all functions defined in a module. However this kind of declaration causes some work when merging branches etc. Its not a big deal but takes time. So does it make sense to add this information using pragmas? {-# HIDE logInfo, logError #-} logInfo :: Int -> String -> (Bool, Double) logInfo = logM INFO "this.module" logError :: Int -> String -> (Bool, Double) logInfo = logM ERROR "this.module" Adding a pragma like HIDE, EXPORT is only a small change but can make a big difference in everyday life ? Can template haskell add those pragmas as well? Marc Weber

3 3

Re: cheap in-repo local branches (just needs implementation)
by Petr Rockai 22 Jul '09

22 Jul '09

Hi, Grant Husbands <darcsusers(a)grant.x43.net> writes: > 1. When you unpull old patches or reorder patches, Darcs alters > existing patch files. This will break other branches that share the > same files. Not true, since the filenames are fully determined by the file content. Hashed repositories will just create a new file for the modified patch. > 2. Similarly, when you pull patches in different contexts, you end up > with slightly-different patches with the same name. Same as above. > 3. With enough unpulling on one branch, you probably break the root > for another branch, by removing the shared inventory behind the head. This can be addressed by a GC policy. It's probably not feasible with current darcs, but keeping around "root" pointers to inventories is not much different from keeping extra roots for pristine. > 4. Pushing and pulling between branches would be very hard to > implement without heavy Darcs involvement. The method in the proposal > will not work, as Darcs in either branch can't necessarily understand > the context produced by the other branch. I'm not sure I follow your argument here. The proposed thing is the exact mechanism behind "darcs push" -- grab context of remote repository, commute patches you have to a common point and create a bundle, then use apply on that bundle... > 5. Updating the working copy correctly for many branch operations > entails knowing how to handle all of the darcs patches that are > different between the branches. Even if you force the user to have no > working copy changes, what about the unversioned extra files, > especially in renamed folders? The "switch" problem wouldn't be any easier whether implemented inside or outside of darcs. This basically entails unapplying patches up to a common point and then applying missing ones. This may or may not work, depending on how much changed the working copy is. I presume we would abort without doing any changes may this break. > 6. As noted in the proposal, it's not known how to make it play nicely > with lazy fetching. I don't expect any problems here. I also don't see the original note? > 7. The branch-knowledge synchronisation requires almost as much > knowledge about how to handle remote Darcs repos as Darcs has. This is likely true. Yours, Petr.

1 0

cheap in-repo local branches (just needs implementation)
by Eric Kow 22 Jul '09

22 Jul '09

Hi everyone, Max Battcher had an idea that I thought I should post on the mailing list. The idea is about making branches in darcs. Right now, we take the view that a darcs branch is a darcs repository plain and simple. If you want to create a branch, all you have to do is darcs get (darcs get --lazy to be faster). While this is very simple, a lot of us think that it's inconvenient (one because it's slow, and two because you have to think of where to put the branch). So darcs users have been asking about in-repo branches for a while. And now, Max has come up with a way to implement them. What's nice about his approach is that it lets us keep the simplicity of darcs, while giving more demanding users a chance to work with branches. It also takes advantage of the Petr Ročkai's Summer of Code project to make darcs faster in our daily lives and for the matter, paves the way for a possible darcs plugin system in the future. On Max's advice, I'm cross-posting to Haskell Cafe. Haskellers: here's a nice chance for you get a cool Darcs feature without not very much effort or Darcs hacking experience :-) More info on: http://bugs.darcs.net/issue555 ------------------------------------------------------------ Max's write-up ------------------------------------------------------------ Here's a quick primer: Basically, darcs >= 2.0 uses a hashed pristine store that acts as a file object cache. An interesting artifact of the pristine.hashed store, which is being pushed into a useful third-party accessible library named hashed-storage, however, is that it does (for many reasons, most co-evolutionary) resemble the git object store. There are several differences, but one of the key differences that applies to the topic at hand is that darcs generally garbage collects pristine.hashed objects much faster than git. Darcs is very quick to garbage collect old objects partly because many aren't all that useful, but mostly because the primary representation for a repository state is the patch store (and inventory), so there is only one root pointer in the pristine store. Petr, the author of the hashed-storage library, briefly discusses this in his most recent design post about the future of hashed-storage: http://mornfall.net/blog/designing_storage_for_darcs.html Here's where the primer meets the topic at hand: A darcs branch consists of three major components: an inventory store, a patch store, and a pristine store. To store multiple branches "in the same place" you need to take care of: 1) storing the alternate inventories, and 2) if you want it to be relatively fast, storing additional objects in the pristine store. (The patch store will already happily hold more patches than are referenced in the current inventory.) (1) is mostly a matter of naming alternate inventories and swapping between them. Thanks to the *ahem* git-like nature of pristine.hashed/hashed-storage: darcs could easily archive (many) more pristine objects, than it will during normal operation, in pristine.hashed and it may be as simple as storing additional, useful "root pointers" visible to hashed-storage so that it knows not to garbage collect the objects from other branches. Here's where the fun happens: It seems to me that a branch switching tool, utilizing darcs' existing repository data stores, could be built almost "purely" on top of mostly just the hashed-storage library (which has been designed for reuse), as it exists today or hopefully with only minor tweaking, and with only minimal interaction with darcs itself. That is, in-repo branching could be provided entirely, today or soon, as a second/third-party tool to darcs. (!) I think this is great from a darcs perspective: darcs itself remains conceptually simple (1 repository == 1 branch), which is something that I for one love about darcs, and doesn't need additional commands in darcs iteslf. But yet, power users (and git escapees) would have easy access to a ``darcs-branch`` tool that provides simple and powerful in-repo switching. Potentially, such a tool is also a great candidate to be an earlier adopter for the darcs library support and can help better define and enhance darcs' public API. (It's also interesting in that it mirrors that hg's support for branches is an addon, and that both hg and git have darcs-like patch queues as addons.) I think this is even better from a hashed-storage perspective: ``darcs-branch`` would be a strong (new) use case for hashed-storage as a public API. The tool would provide good incentive to keep hashed-storage's API clean, and better incentive (than darcs' normal operation) to keep hashed-storage's garbage collection and object compaction strong. (With the 'cheap' cost of in-repo branches primarily a consequence of how well hashed-storage stores the additional objects of multiple branches. As a bonus, normal darcs operations should benefit as well from the gc/compaction optimizations that darcs-branch operations may make more obvious.) At a high-level, a ``darcs-branch`` tool would provide core commands to: 1) Store the current repository state as a new branch by copying the current inventory and inserting a new pristine root for the branch. (``darcs-branch new`` or ``darcs-branch freeze``, perhaps) 2) Switch to a previously stored branch, by making the branch's inventory the new current inventory and the branch's pristine root the new current pristine root; updating the working directory as necessary. (``darcs-branch switch``) Additionally, there would be other useful management tools (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think that these four commands could be done with no darcs interaction at all (unless the branch being switched to has an incomplete/lazy pristine). Useful commands that would need darcs interaction for patch management would be things like ``darcs-branch push`` to push patches between named branches (equivalent at a high level to ``darcs send -o new.dpatch --context branchB.context; darcs-branch switch branchB; darcs apply new.dpatch``), and ``darcs-branch obtain`` to obtain new in-repo local branches from an existing context file, remote/external-local repository, tag, or other matcher (that is, darcs get from one in-repo branch to a new one). I doubt that a ``darcs-branch get`` to download all of the branches other than "current" (or HEAD, if you prefer, or "main" as I prefer) of a remote repository would need any darcs interaction (downloading the inventories and then many/most/all of the pristine objects). We can bet that darcs' usual lazy patch-getting behavior should work out of the box even for multiple branches. Well, that's the general idea, at least. I believe that a willing volunteer and a bit of help from Petr could build such a tool "relatively quickly" and hopefully might even possibly work with today's darcs as it is. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

6 6

Simple quirk in behavior of `mod`
by Nathan Bloomfield 22 Jul '09

22 Jul '09

Hello haskell-cafe; I'm fiddling with this<http://cdsmith.wordpress.com/2009/07/20/calculating-multiplicative-inverses…>blog post about inverting elements of Z/(p), trying to write the inversion function in pointfree style. This led me to try executing statements like n `mod` 0 which in the ring theoretic sense should be n, at least for integers*. (MathWorld agrees. <http://mathworld.wolfram.com/Congruence.html>) But Hugs gives a division by zero error! I'm more of a recreational haskell user and not too familiar with how the Prelude works. But I dug around a bit and saw this inGHC.Real: ( link<http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Real.htm…> ) > a `mod` b > | b == 0 = divZeroError > | a == minBound && b == (-1) = overflowError > | otherwise = a `modInt` b Is there a reason why n `mod` 0 is undefined in Haskell? Maybe this has already been considered for Haskell' and I'm just unaware. I did some digging in the archives and this discussion <http://markmail.org/message/5dmehw4lhu56x4zw#query:haskell%20%22%60mod%60%2…> <http://markmail.org/message/5dmehw4lhu56x4zw> from 2002 is the most relevant one I could find; it is suggested there that n `mod` 0 should be an error. Thanks all- Nathan Bloomfield *- The mod function is defined in the Integral class, and I'm not even sure how to interpret that. It looks kind of like a Euclidean domain.

3 2

Re[2]: [Haskell] TABI 0.1: a typeful tagged cross-language calling convention
by Bulat Ziganshin 21 Jul '09

21 Jul '09

Hello Felipe, Tuesday, July 21, 2009, 7:38:44 PM, you wrote: >> * passing complex datastructures between various languages forth >> and back, providing faster alternative to serialization approach > I've read the code and I don't see how tabi manages to do this. it's not yet implemented :))) my idea is to provide one more basic type, TABI_TABLE=6, that allows to nest TABI_MAPs recursively. also arrays of TABI_* types may be supported > It is serializing as well but it is including the type and name > information, so it seems that at best it would have the same > overhead as just serializing the data without any metadata. my first approach was to use just serialization (it was implemented in Lua sources included). but then i realized that it is monkey work - most time will be spent copying data to buffer, from buffer, searching for delimiters, processing type conversion. i'm pretty sure that C implementation of TABI_MAP will do its work (filling 3-4 words per parameter) an order of magnitude faster than serialization approach. also, serialized data anyway will be need to converted to datastructure like TABI_MAP in order to be used by calls like _str and _int for Haskell code, good optimized serialization library should have comparable speed. moreover, my current approach with malloc() calls probably makes encoding operations much slower if you have any specific needs, we can discuss it. my own needs is mainly combination of first and third clauses of quoted list, so second claim is somewhat artificial :) it is possible but only partially implemented -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

understanding HXT's insertChildrenAfter
by Jake 21 Jul '09

21 Jul '09

Playing on HXT 8.3.0 via cabal on GHC 6.10.2. While there are plenty of useful examples of extract data from XML, applying the appropriate API to transform and/or merging still baffle me. In this case, it is the insertChildrenAfter, let's try it with the following example: given 2 files --- update.xml <?xml version="1.0" encoding="UTF-8"?> <update> <hot>sky is now orange</hot> <hot>fish is fresh</hot> <hot>violets are blue</hot> </update> --- master.xml <?xml version="1.0" encoding="UTF-8"?> <news> <page1> <hot>sky is blue</hot> <hot>roses are red</hot> </page1> <page2> <story>game shipped on sunday</story> </page2> </news> with the intention of augment the master list with the new items: import Text.XML.HXT.Arrow import qualified Text.XML.HXT.DOM as DOM getMaster = readDocument [(a_validate,v_0)] "master.xml" >>> removeDocWhiteSpace getUpdate = readDocument [(a_validate,v_0)] "update.xml" >>> removeDocWhiteSpace selectUpdateArea = getChildren >>> hasName "news" >>> getChildren >>> hasName "page1" updateContent = insertChildrenAfter (selectUpdateArea) (getUpdate >>> getChildren >>> getChildren) main = do runX ( getMaster >>> updateContent >>> putXmlTree "-" ) instead the following tree is produced: ---XTag "/" | +---XTag "hot" | | | +---XText "sky is red" | +---XTag "hot" | | | +---XText "fish is fresh" | +---XTag "hot" | | | +---XText "violets are blue" | +---XTag "news" | +---XTag "page1" | | | +---XTag "hot" | | | | | +---XText "sky is blue" | | | +---XTag "hot" | | | +---XText "roses are red" | +---XTag "page2" | +---XTag "story" | +---XText "game shipped " Can someone give some examples of how insertChildrenAfter works? How about also some general guidelines when comes to merging/grafting XML documents. Jake

1 0

Pruning the Front Page
by Thomas DuBuisson 21 Jul '09

21 Jul '09

All, I think we should remove unmaintained or refocused implementations from the haskell.org front page. This would mean removing: YHC - unmaintained, hasn't built for me in a while LHC - Not a standalone compiler these days - perhaps should be linked as a GHC subproject? Other than those I'd propose NHC but I'm guessing that would get some pushback (even though it currently doesn't build for me). Before anyone brings up HUGS I'll just say that 1) it is used 2) it builds 3) at least it's been updated more recently than the Haskell langauge. Thomas

3 2

Ambiguous type variable - help!
by phil＠beadling.co.uk 20 Jul '09

20 Jul '09

Hi, I'm trying to work out how to handle a choice at runtime which determines what instance of a State monad should be used. The choice will dictate the internal state of the monad so different implementations are needed for each. I've concocted a very simple example to illustrate this (below) - but it doesn't compile because ghc complains that my type is ambiguous arising from my use of 'fromSeq'. I can kind-of see what the compiler is complaining about, I'm guessing because it is the internals of my type which dictate which state Monad to use and it can't know that? Thinking about it I tried making SeqType an instance of Sequence class, but had no luck here. I understand that haskell is static at compile time, so I'm looking for something like a template solution in C++ (rather than a virtual function style implementation). I see there are libraries out their which do this, but I was wondering in my simple example if there was a way of doing this without writing a load of boilerplate code in main (this would get ugly very quickly if you had loads of choices). If this is impossible does anyone have an example / advice of implementing simple template style code in Haskell? Any help or suggestions would be really appreciated. Many Thanks, Phil. Thus just implements a state Monad which counts up from 1 to 10, using either an Int or a Double depending on user choice. It's pointless of course, but illustrates my point. {-# LANGUAGE TypeSynonymInstances #-} import Control.Monad.State.Strict data SeqType = SeqDouble Double | SeqInt Int class SequenceClass a where nextSeq :: State a Int fromSeq :: SeqType -> a instance SequenceClass Int where nextSeq = State $ \s -> (s,s+1) fromSeq (SeqInt i) = i fromSeq _ = 0 instance SequenceClass Double where nextSeq = State $ \s -> (truncate s,s+1.0) fromSeq (SeqDouble d) = d fromSeq _ = 0.0 chooser :: String -> SeqType chooser inStr | inStr == "Double" = SeqDouble 1.0 | inStr == "Int" = SeqInt 1 | otherwise = SeqInt 1 main :: IO() main = do userInput <- getLine let result = evalState (do replicateM 10 nextSeq) $ fromSeq $ chooser userInput print result

2 2

Anglohaskell - wifi signups
by Philippa Cowderoy 20 Jul '09

20 Jul '09

Wifi signups are Anglohaskell are now on the wiki - please add your details by the 31st of July if you want a wifi account at MS Research for the Friday. Alternatively, reply to this email with your full name, institution, country of residence and email address. The Anglohaskell wiki page can be found at http://www.haskell.org/haskellwiki/AngloHaskell/2009 There's still room for more talks if anyone's got something they fancy giving a go - everything from cutting edge research to "what I did with Haskell on my holiday" is welcome, as is everyone from GHC implentors to newbies frantically writing Hello World on their laptop in the back row. -- flippa(a)flippac.org

1 0

FFI problem - possibility of CStringLen overflow?
by Robin Green 20 Jul '09

20 Jul '09

While rewriting cautious-file to use ByteStrings and FFI just now, I came across this potential problem: Why does the FFI specification define CStringLen as (Ptr CChar, Int)? As the FFI specification itself notes, Haskell 98 implementors are allowed to have a quite small range for Int (only up to 2^29-1) - so you could in principle have a very large String which cannot be represented as a CStringLen, or a very large CString which cannot be represented as a CStringLen. They would take up wads of memory, so this has probably never happened yet, but it's in principle possible, no? If so, what are the implications of this for code correctness? -- Robin

3 2

ANNOUNCE: graphviz-2999.1.0.1
by Ivan Lazar Miljenovic 20 Jul '09

20 Jul '09

This is a bug-fix release to fix the various Attribute-related problems in the previous release (2999.0.0.0) spotted mainly by Zsolt Dollenstein. Please disregard version 2999.1.0.0; it had a small bug. Similarly, people should avoid using 2999.0.0.0 unless they don't use any Either-based Attributes. The problem (which took me a while to realise) was that whilst I was using Either to denote that an attribute could take one of two different types of values (e.g. Bool and String) and the parsing for that worked. However, since I was using Show (I know it's bad, it was on my TODO, remember?) to generate the Dot code, then whenever one of these values was converted then either Left or Right would appear, and GraphViz doesn't seem to like that for some reason... I also took the opportunity to define custom types for more Attributes (as they only accept certain String values). Furthermore, GraphViz states that attributes that can accept a boolean value are set to True when the attribute is listed on its own; the library now does this even for those Attributes that use a custom type that combines Bool with something else. One other small change is that the Color Attribute now takes in a list of Colors; if you only want one, use a singleton list (it was either that or a custom datatype that takes either a single Color or a list of Colors...). Note that 2999.1.0.0 accidentally only had singleton Color values for the Color Attribute rather than a list, hence the quick version bump. Nothing else has changed in the library apart from the Attributes. Regarding my request in the previous email about the possible new layout of the DotGraph datatype: How many people actually build DotGraphs by hand or pull them apart by hand? If there were getNodes :: DotGraph -> [Node] and getEdges :: DotGraph -> [Edge] functions available, would you accept an all-in-one data type that just contains a generic list of statements and thus follows upstream more closely? Even leaving aside parsing, this would allow for greater flexibility for creating wild and wacky graphs or for a monadic interface or something for building DotGraphs (which someone has asked me for, but which at the moment I have no idea how to do...). -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Typeclass default implementation in subclasses
by Andy Gimblett 20 Jul '09

20 Jul '09

Hi all, This email is literate Haskell. I have a question about default implementations of typeclasses. > {-# LANGUAGE TypeSynonymInstances #-} > module Thing where > import Text.PrettyPrint.HughesPJ Let say I want to pretty-print some values, enclosed in double quotes. The natural thing to do (within the HughesPJ pretty-printing framework, anyway - and that's where I am in this problem's wider context) is: > ppQuote :: Show a => a -> Doc > ppQuote = doubleQuotes . text . show Now, this works nicely for (say) Int: > x :: Int > x = 1 *Thing> ppQuote x "1" But less nicely for String and Char, because their Show instances already insert double/single quotes respectively: > y :: String > y = "hello" > z :: Char > z = 'a' *Thing> ppQuote y ""hello"" *Thing> ppQuote z "'a'" I don't want this. I'd like them to be "hello" and "a" respectively. So I thought I'd create a typeclass, whose default implementation is as above... > class (Show a) => Quotable a where > quote :: a -> Doc > quote = ppQuote ... but with specialised instances for String and Char (the former seems to need the TypeSynonymInstances extension?): > instance Quotable String where > quote = text . show -- don't need the doubleQuotes call for String > instance Quotable Char where > quote c = quote [c] -- just lift it to String Unfortunately, while this works great for String and Char... *Thing> quote y "hello" *Thing> quote z "a" ... the "default implementation" mechanism doesn't work as I'd expect/hope: *Thing> quote x <interactive>:1:0: No instance for (Quotable Int) arising from a use of `quote' at <interactive>:1:0-6 Possible fix: add an instance declaration for (Quotable Int) In the expression: quote x In the definition of `it': it = quote x What I would _like_ would be for the compiler to say "OK, the Quotable class depends on the Show class, and Int is an instance of Show so Int is also an instance of Quotable, having the default implementation (since there isn't a specialised one for it)" - but clearly it doesn't. Please can someone tell me why this doesn't happen, and if there is a way of making it happen? Also, if there's a more sensible way of attacking this whole problem, I'd be curious to hear it. I should perhaps add that this isn't a huge problem for me, because my instances will in practice tend to be String and Char anyway, and one can of course add Quotable instances for anything else easily enough - but I'm curious now I've come this far. :-) Many thanks! -Andy

2 1

SpecConstr difficulties
by Reiner Pope 20 Jul '09

20 Jul '09

Hi everyone, I've been having some trouble getting SpecConstr to work as I want it to. The following example (see end of email) came up in some code I was playing around with. The loops g1 and g2 both compute the same thing: the maximum element of the "list" (which has been fused away) of numbers from 1 to 10. Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as an accumulator. The Maybe gets filled after the first element is seen, so the Maybe is a Just for almost the entire running of the loop. It would be good to have this recognised by SpecConstr, to create an optimised loop for the Just case. This does indeed happen for g1, but not for g2. My difficulty is that I am only able to produce code similar to g2, i.e. where the pattern matching is in a separate function, 'expose', because the 'expose' function is implemented in a type-class, like in stream-fusion. Is there some way to keep the SpecConstr while leaving the 'expose' as a separate function? Here is the code: > {-# LANGUAGE BangPatterns #-} > > module Test(ans1,ans2) where > > import Prelude hiding(Maybe(..)) > > data Maybe a = Just !a | Nothing > > Nothing `mapp` Just b = Just b > Just a `mapp` Just b = Just (max a b) > > ans1 = g1 Nothing (0::Int) > > g1 m !n = case m of > Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > > ans2 = g2 Nothing (0::Int) > > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) > expose Nothing b = b > expose (Just a) b = a `seq` b On a similar note, when I was having difficulties with this problem, I started to wonder if it would be possible to come up with a more direct way to tell GHC, "do SpecConstr on this variable". From reading the source code of the stream-fusion package, it seems that the current way of doing this is with 'expose' functions like I wrote below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used on function arguments, like: foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... This pragma should say to the GHC something like "ignore conditions H2, H5 and H6 of the SpecConstr paper, for this function and this argument". Cheers, Reiner

1 0

ICFP contest write-up
by Rafael Gustavo da Cunha Pereira Pinto 20 Jul '09

20 Jul '09

For all Portuguese reading haskellers, I am describing my ICFP 2009 contest write-up on my blog. Feel free to comment. http://rafaelgcpp.blogspot.com/search/label/ICFP2009 For the non-Portuguese readers, Google translation tools do a lousy job, but it is still readable. Regards Rafael Gustavo da Cunha Pereira Pinto

1 0

ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
by Robin Green 20 Jul '09

20 Jul '09

I'm pleased to announce the first public release of cautious-file: http://hackage.haskell.org/package/cautious-file This library currently provides a writeFile function that is intended to have three advantages over Prelude.writeFile: 1. There was a controversy a few months ago about the new Linux filesystem ext4, and how existing applications which write certain files naively might expose their users to the risk of data loss after a crash or power failure. (Actually, it turns out that this is not a new issue - certain other filesystems or filesystem mount options can cause similar issues, but few people made a fuss about it.) cautious-file uses the recommended way of writing a file on POSIX (more or less). On non-POSIX systems (i.e. Windows), it tries to do something sensible, but it may not be the best way to do it, and I've only ran the tests on Linux. 2. With almost any filesystem or operating system, saving a file by overwriting it exposes the user to the risk of data loss if there is a crash or power failure. cautious-file creates a temporary file first and only overwrites the file when it has finished writing (on POSIX systems with sane filesystems, at least). 3. Prelude.writeFile is supposed to lock files so that they at least cannot be written to simultaneously in multiple threads. This is good for safety, but might lead to avoidable problems with IO exceptions when one thread tries to open a file for writing which is still being written to by another thread. Again, the use of a randomly-named temporary file avoids this problem (not with certainty, but with a high probability, which is good enough for some applications). It does not prevent all file-related race conditions (nothing with its type signature could!), but if you are sure you don't care which thread wins, you should be able to use cautious-file's writeFile. A variant, writeFileWithBackup, also allows you to supply a custom backup computation to backup old copy(ies) of the destination file (which is not necessary with Prelude.writeFile, because you can just do it before you call Prelude.writeFile, but is necessary with cautious-file). cautious-file is obviously not appropriate for all circumstances - for instance, it's not needed for writing truly temporary files. But of course if it's close to what you need, you can adapt it (and send me a patch if you like). There is a test runner that can be run by running "runhaskell Setup.lhs test" or "cabal test" in a built copy of the source distribution. The tests do not actually verify that data loss doesn't happen if there's a crash! Indeed, attention should be drawn to the standard BSD license - despite the name "cautious-file", there is no warranty. If in doubt, I suggest you take a close look at the source code - it's very short. I'd appreciate comments, patches, pointers to Haskell code that does the same thing already, etc. Thanks, -- Robin

2 2

was: Debugging methods for haskell structured data types the right way in haskell
by Fernan Bolando 20 Jul '09

20 Jul '09

On Sun, Jul 19, 2009 at 7:40 AM, wren ng thornton<wren(a)freegeek.org> wrote: > Fernan Bolando wrote: >> >> The intention is z0 is a system parameter and database, it contains a >> set of info needed to define a particular simulation >> >> it looks like ( [n,m...], [m,o,p]) >> >> n is is a list info settings for the circuit analysis >> m is a list of statistics for the circuits that is need in sub-sequent >> calculation >> m is a list of circuit settings like temperature etc. >> o is a list of matrix solution for non-linear newton raphson >> p is a list of matrix solution for time dependent calculations > > > This would be better as, > > > data SystemParameterDatabase = SystemParameterDatabase > { infoSettings :: InfoSettings > , statistics :: Statistics > , settings :: Settings > , nlnr :: [Matrix Double] > , timeDependent :: [Matrix Double] > } > > data InfoSettings = InfoSettings > { pMSET :: MSET > , aSetting :: A > , bSetting :: B > ... > } > > data Statistics = Statistics > { aStatistic :: A > , anotherStatistic :: A > , bStatistic :: B > ... > } > > data Settings = Settings > { temperature :: Kelvin > , etc :: Etc > } > ... > > > A single-constructor ADT, especially with the labeled-fields syntax, is > pretty close to C structs; no need to reinvent them and give yourself > headaches. > > > Really, the only thing you should be using lists for is a variable-length > sequence of elements drawn from the same type and distinguished only by > their position in the sequence. Whenever the length is fixed or the > (semantic) type of elements can be distinguished from one another (or > altered by pushing/popping the list), then a list is not what you want to be > using because it doesn't capture the intention of the type (and therefore > allows unintelligible values of the type, and inappropriate transformations > on the type). > > -- > Live well, > ~wren This is the kind of code recommendations I was looking. thanks -- http://www.fernski.com

2 1

Problem resizing widget contained in window
by Jeff Heard 20 Jul '09

20 Jul '09

I created a window, like so: Gtk.windowSetTitle win name Gtk.widgetSetName win "Hieroglyph" Gtk.onDestroy win (exitWith ExitSuccess) Gtk.windowSetDefaultSize win w h Gtk.containerResizeChildren win And an GLDrawingArea like so: config ← Gtk.glConfigNew [Gtk.GLModeRGBA, Gtk.GLModeMultiSample, Gtk.GLModeDouble, Gtk.GLModeDepth, Gtk.GLModeAlpha] area ← Gtk.glDrawingAreaNew config Gtk.onRealize area ◊ GL.drawBuffer $= GL.BackBuffers Gtk.onExpose area (λ_ → renderOnExpose bus ≫ return True) and finally show it like this: Gtk.containerAdd win area Gtk.widgetShowAll win Now, if someone resizes the window, the GLArea does not appear to resize along with it. Did I screw something up? -- Jeff

2 1

ANNOUNCE: graphviz-2999.0.0.0
by Ivan Lazar Miljenovic 20 Jul '09

20 Jul '09

I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools. [1] http://www.graphviz.org/ Probably the biggest and most important change in this release is that AFAICT, all 152 attributes utilised/supported by GraphViz [2] are now specified and supported by this library. However, I'm not fully sure how well the parsing of these attributes will turn out; if you notice a bug/problem then please let me know. [2] http://graphviz.org/doc/info/attrs.html I've specified this as being the first in the 2999.0 series of releases. I will switch to 3000.0 when the generic graph class has been released and graphviz switched to using it rather than just FGL. One other future change that I'm considering is to improve the parsing ability of the Dot language. At the moment, graphviz assumes the following layout is followed: * Graph attributes * Nodes with their attributes (clusters are supported only for creation, not parsing). * Edges with their attributes. To match the behaviour of upstream, this will need to be changed into just a list of statements, where a statement is one of five things [3]: * A Node * An Edge * An attribute (either for the graph overall, nodes or for edges) * "ID '=' ID" (not quite sure what this is; some kind of assignment) * A subgraph (clusters are a specific type of subraph) As the way of defining an attribute for a specific grouping of nodes/edges/subgraphs is to have them all listed after the attribute definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do. [3] http://graphviz.org/doc/info/lang.html As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily. Other major changes to this release: ==================================== * Fixed a bug where the Show instance and read function for DotEdge had the from/to nodes the wrong way round. This was not immediately noticed since the Graph -> DotGraph functions created them the wrong way round, so for those users who only used these this was not apparent. Spotted by Neil Brown. * Greatly improved Attribute usage: almost all attributes are now covered with allowed values. * Extend DotGraph to include whether a graph is strict or not and if it has an ID. Also move the directedGraph field. * Make "Dot" refer to the actual dot command and DotArrow refer to the ArrowType (rather than DotCmd and Dot as before). * Make the Data.GraphViz.ParserCombinators module available to end users again, but not re-exported by Data.GraphViz; it has a warning message up the top not to be used. It is there purely for documentative purposes. * Use extensible-exceptions so that base < 4 is once again supported. * Follow the PVP rather than using dates for versions: http://www.haskell.org/haskellwiki/Package_versioning_policy Note that this means that any library/application using more than a trivial sub-set of graphviz will most likely need to be updated. However, now that the PVP is being followed it should be easier to tell in future when updates will be required. Other items I'm wanting to do in future releases: ================================================= * Allow user to choose whether or not the graph is meant to be directed or undirected. * Improve parsing to fully (or at least follow more closely) support Dot. * Improve clustering/subgraph support. * Use a PrettyPrinter rather than Show to generate Dot output. * Improve Output support. * Find and fix the handle closing bug with graphvizWithHandle. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

4 4

ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
by roconnor＠theorem.ca 19 Jul '09

19 Jul '09

> Max Rabkin wrote: >> On Sat, Jul 4, 2009 at 8:38 PM, Andrew >> Coppin<andrewcoppin at btinternet.com> wrote: >> >>> A few reasons: >>> >>> 1. I never knew it existed. ;-) >>> >> >> A good reason. However, it's good to do a quick search over Hackage >> before uploading (or before writing) so you know what's out there. >> >> Also, if you hadn't used an "AC-" prefix, you'd have had a name >> collision. Is there a particular reason why you want your name in the >> package name rather than just the author field? >> I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. >>> 2. It's mind-blowingly complex. >>> >> >> Colour *is* complex. Which is why I'm so glad Russell O'Connor did all >> the hard work for me :) >> > > Well, no, because now I'm going to have to spend a few hours trying to > find out what CIE is before I can even use that library. > > I think really it's just aimed at a different problem. It looks like > it's trying to specify actual real-world colours. [It's news to me that > this isn't fundamentally impossible...] I'm only trying to specify > colours on a computer screen. And as we all know, computer screens > aren't calibrated in any way, and the same RGB value looks different on > each display. But then, I'm only trying to write a fractal generator, so > CIE specifications are somewhat overkill here. ;-) You can use by lib without worrying about the CIE. You can use my library without ever importing or using the word CIE. However, the CIE stuff is there for those who need it. Perhaps I (maybe with some help) need to make a tutorial on the haskell wiki to try to make it less intimidating. >>> 3. It doesn't appear to provide arithmetic over colours. >>> >> >> It provides darken, blend and addition (though addition is called >> mappend rather than (+)). signum, abs and fromInteger don't make a >> huge amount of sense for colours. >> > > Yeah, I implemented signum and so forth for colours and vectors, but > they're not particularly meaningful... [Insert remark here about > Haskell's numeric class hierachy.] > > So mappend gives you colour addition [with the perplexing comments about > "gamut", presumably some kind of small mammal?], but there's no > subtraction? No multiplication? No linear blending? Linear blending is done by the affineCombo function. I think the darken function will do what you mean by multiplication Colour subtraction can be done by adding (using mappend) a colour that has been darkend by a factor of (-1). I don't believe there is any demand for a colour subtraction fuction, so I don't have a name for it. I suppose these sorts of questions can be put nicely into a short tutorial on the wiki. >>> 4. It's parameterised over the component type; my library is hard-coded > to >>> specific types for speed. >>> >> >> My feeling would be to trust the specializer until it lets me down. >> Has it let you down in the past? >> > > Heh, my colour library includes a custom floor implementation that talks > to the GHC primops directly because calling floor is too slow... > > [In case that sounds like idle talk, I had a program go from 10 seconds > to less than 1 second just by using this function. There's a few tickets > about it on the GHC Trac.] Certainly speed is an issue that I haven't tackled yet since I don't know too much about how to optimized Haskell code. I was thinking of sprinkling in some SPECIALIZE pragmas and maybe adding some RULES to make operations more effecient. For example we could have a rule to rewrite floor to some sort of GHC specific fast floor function. (Although that rule probably deserves to be in some sort of more general location). Any help in this direction would be appricated (perferably while keeping things as portable as possible). This all being said, the major problem my code solves is doing blending in a linear colour space. This necessarily make converting to non-linear sRGB for output much slower. So for people who want speed over proper blending, then probably AC-Colour is the package they need to reach for. Essentially the two packages do fill different niches! >> BTW, the EasyRaster package looks useful. >> I haven't looked at EasyRaster yet, but I got excited when I saw it announced. :) -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

10 18

Problem with lazy IO
by Maciej Piechotka 19 Jul '09

19 Jul '09

Hello. I've tried to combine lazy IO and parsec. The hole process is done by network. Currently I have implemented 'short parsers' so I enter them on need. To update state I have following code: parser2nntp :: Monad m => NntpParser m a -> NntpT m a parser2nntp p = do s <- NntpT (gets $ input . connection) e <- runParserT (do v <- p i <- getInput return (v, i)) () "" s case e of Left er -> error $ show er Right (v, i') -> (NntpT (modify (pNI i')) >> return v) where pNI :: Monad m => ByteString ->NntpState m -> NntpState m pNI i s = s {connection = (connection s) {input = i}} However the 4 line (i <- getInput) blocks the execution as trace indicated. String returned have no input available so it should block on evaluation - and here I pass only a reference to it (or rather I think so). What's wrong? PS. Full code is in darsc nntp repository http://code.haskell.org/nntp/ - please note that it seems to require network compiled against parsec 3 - not 2.

1 1

Why is there no Zippable class? Would this work?
by Job Vranish 19 Jul '09

19 Jul '09

I was needing a way to zip generic data structures together today and was very annoyed to find that there is no Zippable class, or variant there of. So I made my own: class (Foldable f, Functor f) => Zippable f where fmaps :: (Foldable g) => g (a -> b) -> f a -> f b fmaps' :: [a -> b] -> f a -> f b -- to save a step on instance implementation zipWith :: (a -> b -> c) -> f a -> f b -> f c zip :: f a -> f b -> f (a, b) unzip :: f (a, b) -> (f a, f b) fmaps fs a = fmaps' (toList fs) a fmaps' fs a = fmaps fs a zipWith f a b = fmaps (fmap f a) b zip = zipWith (,) unzip a = (fmap fst a, fmap snd a) instance Zippable [] where fmaps' (fx:fs) (x:xs) = fx x : fmaps' fs xs fmaps' _ _ = [] --The fmaps function is also quite handy as a replacment for zipWith3, zipWith4, etc... --For example: x = [1, 3, 5, 7, 3] y = [6, 9, 3, 1, 4] z = [2, 4, 0, 8, 2] test = fmap (,,) x `fmaps` y `fmaps` z -- > [(1,6,2),(3,9,4),(5,3,0),(7,1,8),(3,4,2)] --you can also throw in a functor instance to remove the dependency on the Functor class, but it -- might not be worth it: instance (Zippable f) => Functor f where fmap f a = fmaps (repeat f) a Is there any good reason that there isn't something like this in the standard libraries? Or, as far as I can tell, on hackage? If not, then maybe I'll stick it on hackage. - Job Vranish

10 12

A voyage of undiscovery
by Andrew Coppin 19 Jul '09

19 Jul '09

I've been working hard this week, and I'm stumbled upon something which is probably of absolutely no surprise to anybody but me. Consider the following expression: (foo True, foo 'x') Is this expression well-typed? Astonishingly, the answer depends on where "foo" is defined. If "foo" is a local variable, then the above expression is guaranteed to be ill-typed. However, if we have (for example) foo :: x -> x as a top-level function, then the above expression becomes well-typed. I had never ever noticed this fact before. I'm still trying to bend my mind around exactly why it happens. As best as I can tell, top-level functions (and value constructors, for that matter) seem to get a "new" set of type variables each time they're used, but local variables each get a single type variable, so every mention of a local variable must be of the exact same type. Could this be what GHC's weird "forall" syntax is about? Does "forall x." mean that "x" gets replaced with a unique type variable each time? It's an interesting hypothesis... Anyway, not that anybody is likely to care, but I've just spent an entire week writing a program which can type-check simple Haskell expressions. As in, you type in an expression and give types to any free variables it involves (including value constructor functions), and it tells you the type of the expression and all its subexpressions. (Or tells you that it's ill-typed.) It turns out that this is radically less trivial than you'd imagine. (The ramblings above being just one of the issues I blundered into. Others include the subtleties of writing an expression parser, building a pretty-printer with bracketing that works correctly, and the fact that expression processing malfunctions horribly if you don't make all the variable names unique first...) Other issues were mostly related to the difficulty of constantly refactoring code because you're not quite sure what you're trying to do or how you're trying to do it. (And obscure type checker warnings about GADTs...) Well there we are. I don't suppose anybody will be overly impressed, but I'm glad to have finally got it to work. Now, if it could parse more than 10% of Haskell's syntax sugar, it might even be useful for something...

9 15

Debugging methods for haskell
by Fernan Bolando 18 Jul '09

18 Jul '09

Hi all I recently used 2 hours of work looking for a bug that was causing Program error: Prelude.!!: index too large This is not very informative. It did not give me a hint which function was causing this. In C adding a few printf would have helped me, but in haskell I was not sure how to do that. Can anybody point me to some debuggin method everyone uses. After 2 hours I did find the bug eventually. The code can be viewed here. Maybe some reformatting of the code would make finding bugs easier? http://plan9.bell-labs.com/sources/contrib/fernan/escomma/ fernan -- http://www.fernski.com

10 14

Haskell Zippers on Wikibooks: teasing! :)
by Peter Verswyvelen 18 Jul '09

18 Jul '09

After my colleague explained me about zippers and how one could derive the datatype using differential rules, I had to read about it. So I started reading http://en.wikibooks.org/wiki/Haskell/Zippers#Mechanical_Differentiation This page contains the sentence: *"For a systematic construction, we need to calculate with types. The basics of structural calculations with types are outlined in a separate chapter **Generic Programming*<http://en.wikibooks.org/w/index.php?title=Haskell/Generic_Programming&actio…> * and we will heavily rely on this material"* * * However, the generic programming link does not exist yet :-) So although I now have a rough idea about it, I don't understand the details yet, e.g. notation like [image: \mathit{Node}\,A = \mu X.\,\mathit{NodeF}_A\,X] doesn't make much sense to me yet, although I suspect I can read the mu as a lambda on types? Thanks, Peter * *

6 5

uncommon IMO problem - toilet management
by Henning Thielemann 18 Jul '09

18 Jul '09

In the last two days I was invigilator at the International Mathematic Olympics 2009 in Bremen, Germany. There we got a problem different from the official math problems. :-) Eventually I solved it using Haskell. Read the detailed description at http://hackage.haskell.org/package/toilet-0.0.1 I think the problem is simple enough to be used in education of programming. (I also think it would have been better to avoid monads and use lazy list processing.)

2 1

Haskell Weekly News: Issue 126 - July 18, 2009
by Brent Yorgey 18 Jul '09

18 Jul '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090718 Issue 126 - July 18, 2009 --------------------------------------------------------------------------- Welcome to issue 126 of HWN, a newsletter covering developments in the [1]Haskell community. [2]Hac phi is next weekend! With almost 30 people already registered, it looks like we're going to have a fantastic time hacking in Philadelphia. It's still not too late to [3]register! Announcements GHC 6.10.4. Ian Lynagh [4]announced a new patchlevel release of GHC, 6.10.4. This version has very few changes over 6.10.3, but fixes some bugs that could be critical for a few users. See the [5]release notes for details. shelltestrunner 0.6 released. Simon Michael [6]announced the first release of [7]shelltestrunner, a small tool for testing any command-line program by running it through "shell" tests defined with a simple file format. generator 0.5.1. Yair Chuchem [8]announced the release of the [9]generator package, which implements an alternative list monad transformer, a list class, and related functions. GLURaw 1.0.0.0. Sven Panne [10]announced a new [11]GLURaw package, containing full support for all GLU functionality and similar in spirit to the OpenGLRaw package: it is a 1:1 mapping of the C interface, no libraries or headers are needed at build time, and the GLU API entries are resolved dynamically at runtime. OpenGLRaw 1.0.1.0. Sven Panne [12]announced a new version of the [13]OpenGLRaw package, which adds support for a number of OpenGL extensions. ObjectName 1.0.0.0. Sven Panne [14]announced a (tiny) new package, [15]ObjectName, which contains a class corresponding to the general notion of explicitly handled identifiers for API objects, e.g. a texture object name in OpenGL or a buffer object name in OpenAL. StateVar 1.0.0.0. Sven Panne [16]announced the [17]StateVar package, which further modularizes the OpenGL/OpenAL packages. It implements state variables, which are references in the IO monad, like IORefs or parts of the OpenGL state. data-ordlist-0.0.1 and NumberSieves-0.0. Leon Smith [18]announced the release of two new packages: [19]Data.OrdList offers a convenient way for efficiently dealing with lists that you happen to know are ordered, and includes operations such as union, merge, exclusive union, intersection, and difference. [20]NumberSieves includes the Sieve of O'Neill, from "The Geniune Sieve of Eratosthenes" by Melissa O'Neill, which offers an incremental primality sieve based on priority queues. Also included are two array-based generalizations of the Sieve of Eratosthenes: one for factoring a large quantity of small numbers, and another for calculating the phi function for a large quantity of small numbers. graphviz-2999.0.0.0. Ivan Lazar Miljenovic [21]announced a new release of the [22]graphviz package for Haskell, which provides bindings to the [23]GraphViz suite of tools. The biggest and most important change in this release is that all 152 attributes utilised/supported by GraphViz are now specified and supported. uncommon IMO problem - toilet management. Henning Thielemann [24]announced a [25]Haskell package for managing toilet use at the International Mathematical Olympiad. darcs 2.3 beta 4. Petr Rockai [26]announced another darcs 2.3 beta release, which features better Windows support. If you're on Windows, you should be able to install it with 'cabal install darcs-beta' -- give it a try! Google Summer of Code Progress updates from participants in the 2008 [27]Google Summer of Code. space profiling. Gergely Patai has been working on a [28]heap profile manager. fast darcs. Petr Rockai put out another [29]another darcs 2.3 beta release, and made a [30]bunch of other progress including getting darcs up and running on win32, working on hashed-storage, and optimizing 'darcs show contents'. Discussion is closing a class this easy? Conor McBride [31]asked for feedback on some code intended to effectively create a closed type class. laziness blowup exercise. Thomas Hartman [32]challenged readers to squash a memory leak. Blog noise [33]Haskell news from the [34]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Gergely Patai: [35]Introducing the heap profile manager. * FP Lunch: [36]Folding Statistics. * Petr Rockai: [37]soc progress 8. * Greg Bacon: [38]Monadic takeWhile. * Petr Rockai: [39]darcs 2.3 beta 4. * David Amos: [40]Counting symmetries using transversals. * Magnus Therning: [41]XML prettifier in Haskell. * Petr Rockai: [42]soc progress 7. Quotes of the Week * Berengal: For me, understanding the basics/reasoning behind haskell's type system was just a minute meditating on the phrase "what's the square root of hello?" * bitwize: The oleg is to functional studliness as the farad is to capacitance: a hopelessly large base unit. * maartenm: euclidate: to promote a conjecture to an axiom just for the sake of simplicity * RobertGreaye: Some suggest the original English remained in Britain when the North American colonies were founded; others claim it was brought to the Americas by the British settlers, leaving a pale imitation back in Britain. The truth is much stranger: the original English was actually smuggled out of Britain to the West Indies in a wardrobe belonging to General Sir Ralph Abercromby, where it ended up on the island of Trinidad after Sir Ralph took possession of that territory in the name of the British Crown. About the Haskell Weekly News New editions are posted to [43]the Haskell mailing list as well as to [44]the Haskell Sequence and [45]Planet Haskell. [46]RSS is also available, and headlines appear on [47]haskell.org. To help create new editions of this newsletter, please see the information on [48]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [49]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://haskell.org/haskellwiki/Hac_%CF%86 3. http://haskell.org/haskellwiki/Hac_%CF%86/Register 4. http://www.haskell.org//pipermail/haskell/2009-July/021508.html 5. http://haskell.org/ghc/docs/6.10.4/html/users_guide/release-6-10-4.html 6. http://article.gmane.org/gmane.comp.lang.haskell.general/17367 7. http://hackage.haskell.org/package/shelltestrunner 8. http://article.gmane.org/gmane.comp.lang.haskell.general/17366 9. http://hackage.haskell.org/package/generator 10. http://article.gmane.org/gmane.comp.lang.haskell.general/17364 11. http://hackage.haskell.org/package/GLURaw 12. http://article.gmane.org/gmane.comp.lang.haskell.general/17363 13. http://hackage.haskell.org/package/OpenGLRaw 14. http://article.gmane.org/gmane.comp.lang.haskell.general/17362 15. http://hackage.haskell.org/package/ObjectName 16. http://article.gmane.org/gmane.comp.lang.haskell.general/17361 17. http://hackage.haskell.org/package/StateVar 18. http://article.gmane.org/gmane.comp.lang.haskell.general/17355 19. http://hackage.haskell.org/package/data-ordlist 20. http://hackage.haskell.org/package/NumberSieves 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61494 22. http://hackage.haskell.org/package/graphviz 23. http://www.graphviz.org/ 24. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61448 25. http://hackage.haskell.org/package/toilet-0.0.1 26. http://article.gmane.org/gmane.comp.lang.haskell.cafe/61302 27. http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008 28. http://just-bottom.blogspot.com/2009/07/introducing-heap-profile-manager.ht… 29. http://web.mornfall.net/blog/darcs_2.3_beta_4.html 30. http://web.mornfall.net/blog/soc_progress_8.html 31. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61456 32. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61283 33. http://planet.haskell.org/ 34. http://haskell.org/haskellwiki/Blog_articles 35. http://just-bottom.blogspot.com/2009/07/introducing-heap-profile-manager.ht… 36. http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=232 37. http://web.mornfall.net/blog/soc_progress_8.html 38. http://feedproxy.google.com/~r/gbacon/~3/Q-Y-KapB8iI/monadic-takewhile.html 39. http://web.mornfall.net/blog/darcs_2.3_beta_4.html 40. http://haskellformaths.blogspot.com/2009/07/counting-symmetries-using-trans… 41. http://therning.org/magnus/archives/695 42. http://web.mornfall.net/blog/soc_progress_7.html 43. http://www.haskell.org/mailman/listinfo/haskell 44. http://sequence.complete.org/ 45. http://planet.haskell.org/ 46. http://sequence.complete.org/node/feed 47. http://haskell.org/ 48. http://haskell.org/haskellwiki/HWN 49. http://code.haskell.org/~byorgey/code/hwn/

1 0

cabal version issue
by Vasili I. Galchin 18 Jul '09

18 Jul '09

Hello, vigalchin@ubuntu:~/FTP/Haskell/06052009.Swish-0.2.1$ cabal --version cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library vigalchin@ubuntu:~/FTP/Haskell/Swish-0.2.1$ cabal configure --user --prefix=$HOME Warning: swish.cabal: A package using section syntax should require "Cabal-Version: >= 1.2" or equivalent. Warning: swish.cabal: A package using section syntax should require "Cabal-Version: >= 1.2" or equivalent. What is the "Cabal-Version" in the latter? Why I am getting this warning? Thanks, Vasili

2 1

Importance of identity element in finger trees?
by Daniel Peebles 18 Jul '09

18 Jul '09

Hi all, I was looking at finger trees and the tricks for getting priority queues out of them seemed a little hackish, with a distinguished infinity element or maxBound. But it seems (although I have not yet tried it) like in many cases the monoid's identity element wouldn't be necessary (a bit like the difference between fold* and fold*1). Could a finger tree be applied to an arbitrary semigroup? Or is the identity more fundamental than it looks? Thanks, Dan

2 1

catchSTM and asynchronous exceptions
by Peter Robinson 18 Jul '09

18 Jul '09

I couldn't find any information on whether catchSTM catches asynchronous exceptions so I tried to run the following: import Control.Concurrent.STM import Control.Concurrent import Control.Exception import Prelude hiding (catch) test = do tid <- myThreadId forkIO (threadDelay 5000000 >> throwTo tid (AssertionFailed "Exception in forked thread!")) (atomically $ retry `catchSTM` stmHandler) `catch` (ioHandler tid) where stmHandler (e::SomeException) = throw $ AssertionFailed ("Caught Exc. in STM; Rethrowing exception: "++ show e) ioHandler tid (e::SomeException) = print (tid,"Caught Exception in IO: ",e) Yielding the following output: # (ThreadId 6942,"Caught Exception in IO: ",Exception in forked thread!) Apparently the exception is caught by "catch" and not by "catchSTM". So the point is that catchSTM is only meant to be used for non-async exceptions, right? Regards, Peter

1 0

Plot data reconstruction reading pixel colors from image files
by Cetin Sert 18 Jul '09

18 Jul '09

Hi, How can I open and read colors of specific pixels of an image file in Haskell? Which packages, functions do you recommend? You can have a look at the quoted conversation for an idea on what I would like to automate. Best Regards, Cetin Sert > Hi dear *^o^*, > > Here are the points from Figure 37 > > [SEE ATTACHED PNG] > > Cisse > Goni > Kodougou > Nouna > normals > log10s > normals > log10s > normals > log10s > normals > log10s > 0.7999999999999998 > 0.5249999999999999 > 0.4249999999999998 > 0.375 > 0.41249999999999964 > 0.4249999999999998 > 0.8500000000000001 > 1.575 > 1.5999999999999999 > 1.325 > 1.0499999999999998 6.30957344480193 > 3.3496543915782757 > 2.6607250597988084 > 2.371373705661655 > 2.5852348395621885 > 2.6607250597988084 > 7.07945784384138 > 37.583740428844415 > 39.81071705534971 > 21.134890398366466 > 11.220184543019629 -0.5625 > -0.3250000000000002 > 0.16249999999999964 > 0.3374999999999999 > 0.5 > 0.8500000000000001 > 1.4874999999999998 > 2.1375 > 2.2625 > 1.875 > 1.0 0.27384196342643613 > 0.4731512589614803 > 1.4537843856076607 > 2.1752040340195222 > 3.1622776601683795 > 7.07945784384138 > 30.725573652674456 > 137.24609610075626 > 183.02061063110568 > 74.98942093324558 > 10.0 0.7250000000000001 > 0.34999999999999964 > 0.3374999999999999 > 0.5 > 0.625 > 0.6374999999999997 > 0.7624999999999997 > 1.2249999999999999 > 1.5125 > 1.2125 > 0.625 5.308844442309884 > 2.2387211385683377 > 2.1752040340195222 > 3.1622776601683795 > 4.216965034285822 > 4.340102636447436 > 5.787619883491203 > 16.788040181225597 > 32.546178349804585 > 16.31172909227838 > 4.216965034285822 0.3374999999999999 > 0.13749999999999973 > 0.375 > 0.6499999999999999 > 0.5749999999999997 > 0.47499999999999964 > 0.9874999999999998 > 1.825 > 2.025 > 1.4749999999999999 > 0.7624999999999997 2.1752040340195222 > 1.372460961007561 > 2.371373705661655 > 4.46683592150963 > 3.7583740428844394 > 2.9853826189179573 > 9.716279515771058 > 66.83439175686145 > 105.92537251772886 > 29.853826189179586 > 5.787619883491203 > Top to Bottom in the table is Left to Right in the figure. > > > Lots of love, > CS ;-) > > P/S: Sorry it took a bit longer than expected but it was lots of fun! > > ------------------------------------------------------------------- > > > > module Main where > > import Control.Monad > > f x = 3 - (x / 80) -- 80: number of pixels > d x = x - 2 -- pixel offset > > cisse, goni, kodou, nouna :: [Double] > cisse = [178,200,208,212,209,208,174,116,114,136,158] > goni = [287,268,229,215,202,174,123,71 ,61 ,92 ,162] > kodou = [184,214,215,202,192,191,181,144,121,145,192] > nouna = [215,231,212,190,196,204,163,96 ,80 ,124,181] > > disp :: (String, [Double]) → IO () > disp (town,pixels) = do > putStrLn $ town > putStrLn $ ">normals" > mapM_ print $ points > putStrLn $ ">log10s" > mapM_ print $ log10s > putStrLn $ "-------------------" > where > points = map (f . d) pixels > log10s = map (10 **) points > > main :: IO () > main = do > mapM_ disp [("Cisse", cisse),("Goni", goni),("Kodougou", kodou),("Nouna", > nouna)] > > > > -------------------- > > Cisse > >normals > 0.7999999999999998 > 0.5249999999999999 > 0.4249999999999998 > 0.375 > 0.41249999999999964 > 0.4249999999999998 > 0.8500000000000001 > 1.575 > 1.5999999999999999 > 1.325 > 1.0499999999999998 > >log10s > 6.30957344480193 > 3.3496543915782757 > 2.6607250597988084 > 2.371373705661655 > 2.5852348395621885 > 2.6607250597988084 > 7.07945784384138 > 37.583740428844415 > 39.81071705534971 > 21.134890398366466 > 11.220184543019629 > ------------------- > Goni > >normals > -0.5625 > -0.3250000000000002 > 0.16249999999999964 > 0.3374999999999999 > 0.5 > 0.8500000000000001 > 1.4874999999999998 > 2.1375 > 2.2625 > 1.875 > 1.0 > >log10s > 0.27384196342643613 > 0.4731512589614803 > 1.4537843856076607 > 2.1752040340195222 > 3.1622776601683795 > 7.07945784384138 > 30.725573652674456 > 137.24609610075626 > 183.02061063110568 > 74.98942093324558 > 10.0 > ------------------- > Kodougou > >normals > 0.7250000000000001 > 0.34999999999999964 > 0.3374999999999999 > 0.5 > 0.625 > 0.6374999999999997 > 0.7624999999999997 > 1.2249999999999999 > 1.5125 > 1.2125 > 0.625 > >log10s > 5.308844442309884 > 2.2387211385683377 > 2.1752040340195222 > 3.1622776601683795 > 4.216965034285822 > 4.340102636447436 > 5.787619883491203 > 16.788040181225597 > 32.546178349804585 > 16.31172909227838 > 4.216965034285822 > ------------------- > Nouna > >normals > 0.3374999999999999 > 0.13749999999999973 > 0.375 > 0.6499999999999999 > 0.5749999999999997 > 0.47499999999999964 > 0.9874999999999998 > 1.825 > 2.025 > 1.4749999999999999 > 0.7624999999999997 > >log10s > 2.1752040340195222 > 1.372460961007561 > 2.371373705661655 > 4.46683592150963 > 3.7583740428844394 > 2.9853826189179573 > 9.716279515771058 > 66.83439175686145 > 105.92537251772886 > 29.853826189179586 > 5.787619883491203 > ------------------- >

5 4

Re: [Haskell-cafe] is closing a class this easy?
by Conor McBride 18 Jul '09

18 Jul '09

On 18 Jul 2009, at 01:43, Lennart Augustsson wrote: > As far as I know it works. It's an old Oleg trick. Then it probably does work. > The only drawback is that error messages may refer to Private. As I found out when probing its security. "No instance for Moo.Private" shows up. I guess that's what happens when you hide stuff: you get told what stuff's being hidden. In some situations, that's insecure, but here it's ok. Cheers (and have fun in China, Lennart!) Conor

1 0