- Haskell-Cafe - Haskell.org

ICFP 2010: Call for participation
by Wouter Swierstra 03 Aug '10

03 Aug '10

===================================================================== Call for Participation The 15th ACM SIGPLAN International Conference on Functional Programming (ICFP 2010) http://www.icfpconference.org/icfp2010/ Baltimore, Maryland September 25 – October 2 ===================================================================== ICFP 2010 provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. * Program: http://www.icfpconference.org/icfp2010/program.html * Invited speakers: - Mike Gordon ML: Metalanguage or Object Language? - Matthias Felleisen TeachScheme!: A Checkpoint - Guy Blelloch Functional Parallel Algorithms Schedule including related events: * September 25: Workshop on Mechanizing Metatheory (WMM) Workshop on High-Level Parallel Programming and Applications (HLPP) * September 26: Workshop on ML Workshop on Generic Programming (WGP) * September 27-29: ICFP 2010 * September 30: Haskell Symposium Erlang Workshop * October 1: Commercial Users of Functional Programming – Day 1 (CUFP Tutorials) Haskell Implementors' Workshop * October 2: Commercial Users of Functional Programming – Day 2 (CUFP Talks) Registration information: * Registration link: https://regmaster3.com/2010conf/ICFP10/register.php Local arrangements (including travel and accommodation): * http://www.icfpconference.org/icfp2010/local.html * Conference reservation/rate deadline: September 1st Conference organizers: * General Chair: Paul Hudak, Yale University * Program Chair: Stephanie Weirich, University of Pennsylvania * Local Arrangements Chair: Michael Hicks, University of Maryland * Workshop Co-Chairs: Derek Dreyer, Max Planck Institute for Software Systems Christopher Stone, Harvey Mudd College * Programming Contest Chair: Johannes Waldmann, Hochschule für Technik, Wirtschaft und Kultur, Leipzig * Video Chair: Scott Smith, Johns Hopkins University * Publicity Chair: Wouter Swierstra, Vector Fabrics =====================================================================

1 0

new Cabal user question -- installing to Haskell Platform on Windows network drive?
by Peter Schmitz 03 Aug '10

03 Aug '10

I have recently installed the Haskell Platform (for the first time) to a MS Windows network drive; e.g.: H:\aaa\bbb\Haskell Platform\2010.1.0.0\ I did so without admin privs. It has ghc-6.12.1 I need to not install to C:. I would like to install and use Gtk2Hs and Glade on the Platform also. I have used Gtk2Hs and Glade in Haskell (with just ghc, not the Platform), but I have never used Cabal or the Haskell Platform. I see at http://www.haskell.org/gtk2hs/ that Gtk2Hs now comes in a Cabal package ("Gtk2Hs 0.11.0 released"). The info there says you can just install "the Gtk+ libraries", and then do: cabal install gtk2hs-buildtools cabal install gtk I interpret "the Gtk+ libraries" to mean "gtk: the base GUI library" package listed at http://www.haskell.org/gtk2hs/download/ (is that correct?). That is a link to http://hackage.haskell.org/package/gtk which has "gtk-0.11.0.tar.gz (Cabal source package)", which I downloaded and unpacked to a temp directory which now contains "gtk-0.11.0". I've reviewed the Cabal documentation (that came with the Platform) and I'm having a little trouble determining exactly what to do next -- the exact commands to use for my non-C: / network drive installation. (I have not used Cabal before.) I would prefer to do this without admin privs, if possible. ** If anyone could help me out here with a step-by-step, I would appreciate it. Hopefully the procedure for glade will then be similar. Thanks (very much) in advance. -- Peter Schmitz

4 9

Reverse unification question
by Martijn van Steenbergen 02 Aug '10

02 Aug '10

Dear café, Given: > instance Category C > y :: forall r. C r (A -> r) I am looking for the types of x and z such that: > x . y :: forall r. C r r > y . z :: forall r. C r r Can you help me find such types? I suspect only one of them exists. Less importantly, at least to me at this moment: how do I solve problems like these in general? Thank you, Martijn.

3 2

Microsoft's Singularity Project and Haskell
by Vasili I. Galchin 02 Aug '10

02 Aug '10

Hello, In the latest ACM CACM is a paper on Singularity. Here also is an overview: http://lambda-the-ultimate.org/node/1081. I haven't finished the CACM paper yet but I only mention of languages like C# and F#. Singularity is predicated around providing a safe environment. IMO Haskell is even better than their languages. My $.02. Regards, Vasili

9 11

Fwd: Bug in Parsec.Token
by Derek Elkins 02 Aug '10

02 Aug '10

This is a forward of a message from March 4th. ---------- Forwarded message ---------- From: Derek Elkins <derek.a.elkins(a)gmail.com> Date: Thu, Mar 4, 2010 at 9:43 PM Subject: Re: Bug in Parsec.Token To: Don Stewart <dons(a)galois.com> Cc: Greg Fitzgerald <garious(a)gmail.com>, Antoine Latter <aslatter(a)gmail.com>, "Sittampalam, Ganesh" <ganesh.sittampalam(a)credit-suisse.com>, Ian Lynagh <igloo(a)earth.li>, libraries(a)haskell.org I'm not subscribed to libraries, so this won't go there. One of the first benchmarks against Parsec 3.0.0 was John MacFarlane's here: http://www.haskell.org/pipermail/haskell-cafe/2008-March/040258.html In it, he found Parsec 3.0.0 about 2x slower for his benchmark. I can't recreate his benchmark, but I suspect it is a variant of one he describes here:http://code.google.com/p/pandoc/wiki/Benchmarks I decided to do a similar benchmark. I used Parsec 2.1.0.1, Parsec 3.0.1, and Parsec 3.1.0. Of particular note, building all three required -only- changing which library pandoc depended on. No change to the source was necessary. All tests in pandoc's test suite passed for all versions. Doing that benchmark with a different input file, this file [http://wpcal.firetree.net/wp-content/plugins/PHP%20Markdown%201.0.1k/PHP%20…] concatenated to itself 32 times to produce a 730KB markdown file, I get the following times for the last three of four runs. Parsec 2.1.0.1 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-2.1.0.1 --strict t.text > /dev/null real 0m9.863s user 0m7.792s sys 0m0.160s real 0m9.756s user 0m7.792s sys 0m0.132s real 0m10.123s user 0m7.976s sys 0m0.168s Parsec 3.0.1 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-3.0.1 --strict t.text > /dev/null real 0m22.008s user 0m17.445s sys 0m0.324s real 0m21.789s user 0m17.433s sys 0m0.160s real 0m21.754s user 0m17.677s sys 0m0.168s Parsec 3.1.0 derek@derek-laptop:~/temp/pandoc-1.3/dist/build/pandoc$ time ./pandoc-3.1.0 --strict t.text > /dev/null real 0m10.708s user 0m8.201s sys 0m0.168s real 0m11.078s user 0m8.401s sys 0m0.232s real 0m10.797s user 0m8.513s sys 0m0.224s These results recreate the approximate 2x slowdown that John originally mentioned between Parsec 2.1.0.1 and Parsec 3.0. It also demonstrates that Parsec 3.1.0 is significantly faster than 3.0.1 but still a little bit slower than Parsec 2.1.0.1. On Thu, Mar 4, 2010 at 4:39 PM, Don Stewart <dons(a)galois.com> wrote: > derek.a.elkins: >> Who is going to maintain "Parsec 4"? >> >> I'm completely against this. If people absolutely must have exactly >> Parsec 2's implementation we can simply copy it into Parsec 3, and the >> "compatibility" layer, in that case, will simply -be- Parsec 2. I've >> considered this as a temporary solution for the performance issues >> just so people could move to Parsec 3 dependencies, but that should >> not be necessary now, and even then I considered it a much less than >> ideal solution. >> >> If the community wants to freeze on Parsec 2, then I have no problem >> renaming the package, otherwise I think it is both unnecessary and a >> waste of effort. >> > > The problem is the ongoing lack of confidence in Parsec 3's performance. > The new release goes some way to addressing this, but I think this has > gone unaddressed for too long. > > Can someone address the lingering concern with benchmarks against parsec 2? > > -- Don >

1 0

ANNOUNCE: parsec2 - a fork or parsec circa 2.1
by Antoine Latter 02 Aug '10

02 Aug '10

Hello, I would like to announce the parsec2 package, which is a maintained fork of the parsec library as of version 2.1.0.1. This project is for folks who would like to use the simpler interface and fewer extensions relative to parsec-3.0+, but don't want to rely on an old version of a package on hackage. Parsec is designed from scratch as an industrial-strength parser library. It is simple, safe, well documented (on the package homepage), has extensive libraries and good error messages, and is also fast. Changes relative to parsec-2.1.0.1: * Added haddocks done for parsec-3 * in Parsec.Token, sort names after accounting for case sensitivity, not before from: Greg Fitzgerald When I say that I'm maintaining the parsec2 package, that means I am accepting bugfix patches and doing work to ensure that the package builds on the current version of GHC. Patches are welcome to support building on any other Haskell implementations. Any inovations in the field of parser combinators will be happening in other venues. Documentation patches are also welcome. I'm not quite sure what to do about the fact that both parsec2 and mainline parsec provide modules of the same name. If there's motion towards using the parsec2 package, we might be able to deprecate and then retire the compatibility layer provided by parsec-3.*. Links: On Hackage: http://hackage.haskell.org/package/parsec2-1.0.0 Source repository: darcs get http://code.haskell.org/parsec2/parsec2 Report a bug: http://trac.haskell.org/parsec2/newticket Antoine

5 6

ANNOUNCE: Takusen 0.8.6
by Jason Dagit 02 Aug '10

02 Aug '10

Hello, The Takusen team would like to announce the latest release of Takusen, 0.8.6. This is primarily a bug fix and test suite enhancement release. The most notable new feature is limited support for string encodings with ODBC. The full list of changes is included at the at the end of this announcement. = Interested in Takusen development? = Takusen is looking for a new long term maintainer. I have agreed to fill the role of maintainer for now, but we are seeking an enthusiastic individual with spare time and a desire to lead Takusen development. = How to get it = This release is available on hackage: cabal update && cabal install Takusen The source code is available on code.haskell.org: darcs get http://code.haskell.org/takusen = New features = - Alistair Bayley: * Database/PostgreSQL/PGFunctions.lhs: show instance for UUID prints Word64s in hex. * Database/PostgreSQL/Enumerator.lhs: add UUID and marshaling functions. * Database/PostgreSQL/PGFunctions.lhs: add UUID and marshalling functions. * Database/ODBC/OdbcFunctions.hsc: add support for different String encodings. New functions to marshal to/from various encodings (Latin1, UTF8, UTF16), and bind/get functions changed to use these. - Daniel Corson * binary data with postgres = Bug fixes = - Alistair Bayley: * Database/ODBC/OdbcFunctions.hsc: fix bug in mkBindBufferForStorable for Nothing (null) case: pass -1 (sqlNullData) as value size. * Database/ODBC/OdbcFunctions.hsc: use sqlNullData in bindParamString Nothing case, rather than -1. A bit more descriptive. * Database/ODBC/Enumerator.lhs: store bind buffers in stmt object, so we retain reference to them for lifetime of statement. Destroy with statement (well, lose the reference). Should fix bind errors found by Jason Dagit. * Database/ODBC/Enumerator.lhs: Oracle only supports two transaction isolation levels (like Postgres). String output bind parameters have max size 8000 (we use 7999 because module OdbcFunctions adds one to the size). * Database/ODBC/OdbcFunctions.hsc: string parameters have different SQL data types when binding columns (SQL_CHAR) and parameters (SQL_VARCHAR). Oracle only supports two transaction isolation levels. * Database/PostgreSQL/PGFunctions.lhs: fix byteaUnesc and add byteaEsc. = Refactoring = - Jason Dagit: * update urls in cabal file - Alistair Bayley: * Takusen.cabal: fixed QuickCheck version spec. * Takusen.cabal: bump version to 0.8.6. * Database/ODBC/OdbcFunctions.hsc: makeUtcTimeBuffer: pass struct size as both buffer size and data size in call to mkBindBuffer. * Database/ODBC/OdbcFunctions.hsc: mkBindBufferForStorable calls mkBindBuffer (reduces duplicated code). * Database/ODBC/Enumerator.lhs: add instance for EnvInquiry to change session char encoding. * Database/ODBC/Enumerator.lhs: add comments to beginTransaction. * Database/Util.lhs: print "printArrayContents", to match function name. * Database/PostgreSQL/Enumerator.lhs: expose byteaEsc and byteaUnesc. = New tests and changes to tests = - Alistair Bayley: * Database/ODBC/Test/OdbcFunctions.lhs: added testBindDouble to test Nothing (null) case for Storable types. * Database/ODBC/Test/OdbcFunctions.lhs: split transaction isolation level tests so there is one test per level. String marshaling tests use 0x10FF40 as max unicode codepoint, because that keeps Oracle happy. Max size for String parameter buffer is 7999 (SQL Server restriction). Don't bury errors raised by tests; print, but continue. Fix fixture cleanup bug in testBindOutput (dropped wrong procedure). * Database/ODBC/Test/Enumerator.lhs: suffix xxx to bindOutput test expected value. * Database/PostgreSQL/Test/PGFunctions.lhs: tests for UUID. * Database/PostgreSQL/Test/Enumerator.lhs: round-trip test for UUID. * Database/PostgreSQL/Test/PGFunctions.lhs: test select of UUID value. * Database/ODBC/Test/OdbcFunctions.lhs: set client charset to UTF8 when postgresql. * Database/Test/Enumerator.lhs: add order-bys to tests with unions. * Database/PostgreSQL/Test/PGFunctions.lhs: add order-by to union test. * Database/ODBC/Test/Enumerator.lhs: set char encoding to UTF8. inquire InfoDbmsName already returns lowercase. * Takusen.cabal: add random to build-depends for tests. * Database/Test/Enumerator.lhs: make test fixtures more friendly to MS Access. * Database/ODBC/Test/OdbcFunctions.lhs: tests modified for MS Access (date tests), plus use new char-encoding aware functions. * Database/ODBC/Test/Enumerator.lhs: change boundary dates test to not use union. Union seems to make MS Access choke. * Database/PostgreSQL/Test/PGFunctions.lhs: add tests for bytea, including QuickCheck roundtrip. * Database/PostgreSQL/Test/Enumerator.lhs: add bytea bind and select test.

9 18

Laziness question
by michael rice 02 Aug '10

02 Aug '10

From: http://en.wikibooks.org/wiki/Haskell/Laziness Given two functions of one parameter, f and g, we say f is stricter than g if f x evaluates x to a deeper level than g x Exercises 1. Which is the stricter function? f x = length [head x] g x = length (tail x) Prelude> let f x = length [head x] Prelude> let g x = length (tail x) Prelude> f undefined 1 Prelude> g undefined *** Exception: Prelude.undefined Prelude> So, g is stricter than f? Wouldn't both functions need to evaluate x to the same level, *thunk* : *thunk* to insure listhood? f x = length [head *thunk* : *thunk*] g x = length (tail *thunk* : *thunk*) Michael

13 20

Cabal LD errors
by wren ng thornton 02 Aug '10

02 Aug '10

So I'm getting some weird linking errors from cabal-install when doing `cabal configure && cabal build` ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o ld warning: atom sorting error for _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Max_closure_tbl and _postazm0zi2zi0_DataziMonoidziOrdziArgmax_Min_closure_tbl in dist/build/Data/Monoid/Ord/Argmax.o But cabal doesn't quit with an error code or anything. Doing `ghc --make Data/Monoid/Ord/Argmax.hs` works just fine without warnings. Anyone know what could cause them, or how to fix it? -- Live well, ~wren

3 3

Chart package segfaults when rendering to window
by briand＠aracnet.com 02 Aug '10

02 Aug '10

Seems to be ok rendering to png files. I was wondering if anybody has been using Chart and may have seen the same thing. I'm running ghc 6.12.1 and the latest and greatest gtk2hs :-) Thanks, Brian p.s. the amplitude modulation

4 4