- Haskell - Haskell.org

Midlands Graduate School 2007
by Graham Hutton 27 Nov '06

27 Nov '06

+--------------------------------------------------------------------+ Midlands Graduate School in the Foundations of Computing Science MGS 2007 16-20 April 2007 University of Nottingham, UK The Midlands Graduate School (MGS) in the Foundations of Computing Science was established in 1999, and organises an annual Spring School on the mathematical foundations of computing. It is primarily aimed at PhD students, but everyone is welcome to attend, including computer scientists, mathematicians, and participants from outside of the UK. PROGRAMME The programme will consist of ten short courses given over a period of five days. The speakers are as follows: Roy Crole Operational Semantics Neil Ghani Category Theory Paul Levy Typed Lambda Calculus Thorsten Altenkirch Dependently Typed Programming Roland Backhouse Algorithmic Problem Solving Martin Escardo Domain Theory and Denotational Semantics Achim Jung Stone Duality Henrik Nilsson Advanced Functional Programming Colin Stirling Concurrency Theory Steve Vickers Topology and Logic LOCATION The school will be held on the Jubilee Campus of the University of Nottingham, which has won many awards for its design and environmental features. Nottingham is centrally located in the UK, and is easily reachable by road, rail and air (Nottingham East Midlands Airport.) REGISTRATION The registration fee will be around 350 pounds, including accommodation. We also hope to have a number of free places for PhD students. To register your interest in MGS 2007, and be informed when registration is open (the number of places will be limited), please contact the organiser, Henrik Nilsson <nhn(a)cs.nott.ac.uk>. FURTHER DETAILS Google search - MGS 2007 Web page - http://www.cs.nott.ac.uk/~nhn/MGS2007/ Xmas seminars - http://www.dcs.shef.ac.uk/~georg/mgs_xmas06.html +--------------------------------------------------------------------+ This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

1 0

Announcement: cabal-test
by Lemmih 26 Nov '06

26 Nov '06

Greetings fellow hackers, It's my great pleasure to announce cabal-test, the automatic tester for Cabal projects. The cabal-test tool is capable of testing embedded quickcheck properties in any and all cabalized projects. The tests are currently executed in parallel with pqc. QC properties can reside anywhere in the code and don't have to be exported. Requirements: * GHC-6.6 * pqc (http://www.cse.unsw.edu.au/~dons/code/pqc/) Future goals: * Use Haddock information when printing test names. * Ability to test multiple targets simultaneously. Example usage: > $ ./cabal-test > Testing cabal-test-0.1 > No library > Testing executable: cabal-test > 2: Tests.prop_sort2 : OK, 100 tests. > 2: Tests.prop_sort3 : OK, 100 tests. > 2: Tests.prop_sort4 : OK, 100 tests. > 2: Tests.prop_sort6 : OK, 100 tests. > 1: Tests.prop_sort1 : OK, 100 tests. > 2: Tests.prop_sort5 : OK, 100 tests. > $ ./cabal-test --help > Usage: cabal-test [OPTION] [PATH] > > Options: > -h, -? --help Show this help text > -v[n] --verbose[=n] Control verbosity (n is 0-5, normal verbosity level is 1, -v alone is equivalent to -v3) > -w path --ghc-path=path Use this command as ghc > -n n --threads=n Use 'n' threads. Default is 2 > -t n --tests=n Depth of test. Default 100 > -p prop --proptag=prop Tests must contain this tag. Default 'prop_'. The darcs repository is available at: http://darcs.haskell.org/~lemmih/cabal-test -- Cheers, Lemmih PS: I'm so glad we're not using Makefiles anymore.

2 2

ANNOUNCE: QuickCheck 2 development version
by Björn Bringert 24 Nov '06

24 Nov '06

This is just a quick announcement that the development version of QuickCheck 2 is now available in a public darcs repository. Some highlights: - Shrinks failing test cases. - Supports testing monadic code. - Handles exceptions gracefully. - coarbitrary has moved to a separate class, to make it easier to write simple instances of Arbitrary. - Type-level modifiers for changing test data generation (e.g. NonNegative). - Magic function table printing. - User-defined actions when properties fail. You can get it with: darcs get http://www.cs.chalmers.se/~bringert/darcs/QuickCheck/ This is a development version, and the API is not necessarily stable yet. It uses the same module names as QuickCheck 1, Test.QuickCheck.*, but it breaks backwards compatibility in many cases. Use explicit package versioning if you need to use it alongside QuickCheck 1. You can build the code and API documentation with Cabal, see README for instructions. Happy hacking! Koen & Björn

3 2

base libraries
by Bulat Ziganshin 24 Nov '06

24 Nov '06

Hello libraries, current situation when Base lib includes everything, from 'const' to starship control, creates serious problems for upgrading to next GHC version. this problem arise because every GHC version arrives with its own, non-upgradable version of Base library and even minor API changes here results in total loss of ability to use new ghc version without #ifdef workarounds it seems strange, but even in this situation some developers prefer to include their modules in base lib instead of providing them as separate libs that can be easily upgraded using Cabal so that any library version can be used with any version of ghc after analyzing the situation, i concluded that source of problem, at least partially, is GHC HQ's policy of packaging libraries with GHC. The list of such libraries is *closed* and odd at first look. why, for example, it includes 2 of 4 regexp libs? at last end, we can learn that this is the list of libs required to build ghc itself! unfortunately, ghc building process don't require FilePath or ByteString support. this results in situation when authors of these libs, looking for a way to include their libs in every ghc distro, don't find other solution except for including them in Base lib. moreover, while Simon & Ian argued against inclusion of these very useful libs in base libs set, they don't have anything against inclusion of the same code in Base lib i'm all for docracy, but not in this case. having the experience of patching the program after each ghc upgrade, and having a bunch of conditionally compiled code in my libs, i can easily imagine ghc version hell that these new modules will provide for us so, i think, it is time to revise ghc libraries policy. i propose to split libs into the 3 "rings": core, base and other * core libs includes ghc version dependent libs. currently it's base, stm and th * base libs are libs, which is guaranteed to be shipped with *every* haskell distribution. on windows, it should be a part of monolithic installer while on unixes these libs may be a separate packages, but porters should ensure that they ported all these libs too this set should include only small and widely used libs, what is mainly datastructure processing ones. my current list includes regexps, bytestring, filepath, time, mtl, fgl, newbinary and so on * other libs are either too specific or too large, such as gui, database and xml ones. these may be included in some distros or installed separately these rules don't say anything about ghc self-building process. it will be great to maintain the list of libraries, required to do it, separately and while we are here - splitting of Base library should be very easy task. its ghc version specific part is in GHC.* modules. these modules should be moved into the new Core library. plus a few modules from Data.* or System.* hierarchy they imports. plus a few modules imported by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at least between various GHC versions. and independent on this work, we can always look into moving pieces of Base into independent libs. as a rule of thumb, everything not used in Base lib may be moved outside of it. of course, these new libs should be included in base libs set in particular, my hottest hope is that ghc 6.6.1 will be shipped with fps 0.8 as separate library that will provide both backward compatibility with 6.6 and will allow to upgrade fps without recompiling ghc itself :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 5

Library versioning policy
by Bulat Ziganshin 24 Nov '06

24 Nov '06

Hello haskell, We all know what is a "DLL hell" - if some program written against version 2.0 of library, then using version 1.0 or 3.0 of the same library when program compiled may call all sorts of devil there is a great solution of this problem - Eternal Compatibility Theory. unfortunately, it's so great that seldom used on practice because it requires significant efforts from library developer i propose another solution for this problem which don't require to write anything and just impose some policies both for library developer and user library developer should just explicitly declare and obey some policy of incrementing library versions which will allow library user to select proper range of versions which are guaranteed to work with his code. i propose the following as standard policy: * major version change (2.2->3.0) means total incompatibility. all sorts of changes may come * middle version change (2.1.3->2.2) means addition of new facilities (functions, constructors, classes...). in most cases, such semi-compatible version can be used if that's done with caution * minor change (2.1.1->2.1.2) means only internal changes and bugfixes other policies may be used as well, library developer should just declare his policy at the library birth and use it consistently this will allow library users to declare in their cabal files range of library versions they are accepted and be sure that this range will include latest bugfixes but don't include any incompatible changes. then Cabal (which now can handle many versions of the same lib) should select latest acceptable version of library requested and make it available for compilation say, if i wrote my program using Streams 1.2.1, i can specify Build-Depends: Streams 1.2.* or, if i brave/accurate enough: Build-Depends: Streams 1.* and Cabal should select the best library available at build time -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Streams 0.1.7 library announce
by Bulat Ziganshin 24 Nov '06

24 Nov '06

Hello haskell, I'm glad to present Streams library version 0.1.7. If you don't yet know, Streams is a fast extensible I/O and serialization library ( http://haskell.org/haskellwiki/Library/Streams ). Main changes against previous version: * true support for GHC 6.6 * support of files larger than 4 gb on windows (see FD5gb.hs example) * files are now open in shared mode on all systems The most dramatic change, though, is that Pupeno <pupeno(a)pupeno.com> has taken a work of polishing, unix testing, packaging and distributing the library, so now it contains: * haddock'ized internal docs * ready to be included in any unix packaging system * semi-automatic self-testing system ;) To get Streams 0.1.7, you can download one of http://pupeno.com/software/streams/Streams-0.1.7.tar.bz2 http://pupeno.com/software/streams/Streams-0.1.7.tar.gz or you can get it from its repository by running: darcs get --tag=0.1.7 http://software.pupeno.com/Streams-0.1 Streams-0.1.7 You can also download and keep track of the 0.1 branch, which is supposed to remain stable and only get bug-fixes by running darcs get http://software.pupeno.com/Streams-0.1/ and then run 'darcs pull' inside it to get further changes. To get the latest unstable and fluctuating version, the development version, run: darcs get http://software.pupeno.com/Streams/ Note: as of this moment, while the project is being darcsified you are not going to find anything useful there, but we expect that to change. Preferably, you should send patches to code to Bulat.Ziganshin(a)gmail.com and to other parts of library to pupeno(a)pupeno.com . Documentation may be edited right at the project homepage, which remains http://haskell.org/haskellwiki/Library/Streams -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

ANNOUNCE: PQC: QuickCheck in the Age of Concurrency
by dons＠cse.unsw.edu.au 23 Nov '06

23 Nov '06

------------------------------------------------------------------------ PQC: QuickCheck in the Age of Concurrency An SMP parallel QuickCheck driver ------------------------------------------------------------------------ Do you: * Have (or want) lots of QuickCheck properties? * Run them often (maybe on every darcs commit)? * Tired of waiting for the testsuite to finish? * Got a multi-core box with cpus sitting idle...? Yes? You need Parallel QuickCheck! PQC provides a single module: Test.QuickCheck.Parallel. This is a QuickCheck driver that runs property lists as jobs in parallel, and will utilise as many cores as you wish, with the SMP parallel GHC 6.6 runtime. It is simple, scalable replacement for Test.QuickCheck.Batch. An example, on a 4 cpu linux server, running 20 quickcheck properties. With 1 thread only: $ time ./a.out 1 1: sort1 : OK, 1000 tests. 1: sort2 : OK, 1000 tests. 1: sort3 : OK, 1000 tests. 1: sort4 : OK, 1000 tests. ... ./a.out 1 > x 18.94s user 0.01s system 99% cpu 18.963 total 18 seconds, 99% cpu. But I've got another 3 2.80GHz processors sitting idle! Let's use them, to run the testsuite faster. No recompilation required. 4 OS threads, 4 Haskell threads: $ time ./a.out 4 +RTS -N4 > /dev/null ./a.out 4 +RTS -N4 > /dev/null 20.65s user 0.22s system 283% cpu 7.349 total 283% cpu, not bad. We're getting close to being limited by the length of the longest running test. Or on a dual core macbook, thanks to Spencer Janssen for macbook data and testing: 1 thread: ./Example 1 17.256s 2 threads: ./Example 2 +RTS -N2 10.402s Get it! Homepage: http://www.cse.unsw.edu.au/~dons/pqc.html Haddocks: http://www.cse.unsw.edu.au/~dons/pqc/ Example : http://www.cse.unsw.edu.au/~dons/code/pqc/examples/Example.hs darcs get http://www.cse.unsw.edu.au/~dons/code/pqc Happy, quick checking, Don

1 0

SYB Documentation is inconclusive.
by Arthur van Leeuwen 23 Nov '06

23 Nov '06

L.S., lately I've been playing with Data.Generics and records. I would like to write a generic method to output to e.g. CSV files. Given MissingH.CVS that problem reduces to a generic method to take lists of records to lists of lists with shown record fields, with as first element a list of the field names. That is, something quite like: > totable :: [RecordType] -> [[String]] > totable rs = fields (head rs) ++ map showrecord rs > where fields a = constrFields . head . dataTypeConstrs . dataTypeOf $ a > showrecord = gmapQ (show . toConstr) However, there are no guarantees whatsoever that the order of the fieldnames returned by constrFields corresponds to the order in which gmapQ returns the results for the children (that is the fields, in this case) of the records. Furthermore, I see no way of forcing such an order otherwise, other than writing boilerplate myself. So, is there something I just haven't seen in the lib yet, is something missing, or is just the documentation inconclusive and does the library behave as I want it to? Doei, Arthur. -- /\ / | arthurvl(a)cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching

2 2

Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
by Cale Gibbard 23 Nov '06

23 Nov '06

On 23/11/06, Jason Dagit <dagit(a)eecs.oregonstate.edu> wrote: > A comment on that video said: > > ----- BEGIN QUOTE ---- > It seems to me that STM creates new problems with composability. > You create two classes of code: atomic methods and non atomic methods. > > Nonatomic methods can easily call atomic ones – the compiler could > even automatically inject the atomic block if the programmer forgot. > > Atomic methods and blocks cannot be allowed to call nonatomic code. > The nonatomic code could do I/O or other irrevocable things that would > be duplicated when the block had to retry. > ---- END QUOTE ---- > > I imagine an example like this (some pseudo code for a side effect > happy OO language): > > class Foo { > protected int counter; // assume this gets initialized to 0 > public doSomething() { > atomic{ > counter++; > Console.Write("called doSomething execution# " + counter); > // something which could cause the transaction to restart > } > } > public doOtherThing() { > atomic{ > doSomething(); > // something which could cause the transaction to restart > } > } > } > > Now imagine doSomething gets restarted, then we see the console output > once each time and counter gets incremented. So one solution would be > to move the side effects (counter++ and the console write) to happen > before the atomic block. This works for doSomething, but now what if > we called doOtherThing instead? We're back to having the extra > side-effects from the failed attempts at doSomething, right? We just > lost composability of doSomething? I'm assuming counter is only meant > to be incremented once per successful run of doSomething and we only > want to see the output to the log file once per successful run, but it > needs to come before the log output inside doSomething so that the log > makes sense. > > I realize STM is not a silver bullet, but it does seem like > side-effects do not play nicely with STM. What is the proposed > solution to this? Am I just missing something simple? Is the > solution to make it so that Console.Write can be rolled back too? > > Thanks, > Jason The solution is to simply not allow side effecting computations in transactions. They talk a little about it in the video, but perhaps that's not clear. The only side effects an atomic STM transaction may have are changes to shared memory. Another example in pseudocode: atomic x <- launchMissiles if (x < 5) then retry This is obviously catastrophic. If launchMissiles has the side effect of launching a salvo of missiles, and then the retry occurs, it's unlikely that rolling back the transaction is going to be able to put them back on the launchpad. Worse yet, if some variable read in launchMissiles changes, the transaction would retry, possibly causing a second salvo of missiles to be launched. So you simply disallow this. The content of a transaction may only include reads and writes to shared memory, along with pure computations. This is especially easy in Haskell, because one simply uses a new monad STM, with no way to lift IO actions into that monad, but atomically :: (STM a -> IO a) goes in the other direction, turning a transaction into IO. In other languages, you'd want to add some static typechecking to ensure that this constraint was enforced. - Cale

2 1

help with happy/alex
by robert bauer 22 Nov '06

22 Nov '06

Hi, I have a .y and .x file. The alex -g _.x gives me a .hs file and happy -g -a -c _.y gives me a .hs file. I then use ghc -c alex.hs to get a a .o and a .hi file. This works great. Unfortunately ghc -c happy.y doesn't work -- it says that it the module name for the lexer doesn't match. I've attached the .y and .x files. Also, I cannot figure out what I need to do in the parser to call the lexer and I don't know how to kick start the parser -- I have no clue what to put in third, main.hs, module. Any help would be appreciated.

1 0