January 2006 - Haskell

Spring School on "Datatype-generic programming", Call for Participation
by Fermin Reig 17 Jan '06

17 Jan '06

(Apologies for multiple copies) Call for Participation Spring School on Datatype-Generic Programming http://www.cs.nott.ac.uk/ssdgp2006/ University of Nottingham, UK 24-27 April 2006 ************ Background and objectives ************ Generic programming is a thriving research area aimed at making programming more effective by making it more general. This school aims to give participants insights into the applications of datatype-generic programming and the current research challenges in the area. This school is a successor to the Summer School and Workshop on Generic Programming, held in Oxford in August 2002 (lecture notes appeared as volume 2793 of LNCS). ************ Technical programme ************ The lectures will be tutorial-style (as opposed to conference-style) and will be accessible to beginning computing science postgraduates. The scientific programme consists of six courses given by renowned specialists, and a student session. The list of courses is the following: * Thorsten Altenkirch (University of Nottingham): (in collaboration with Conor McBride and Peter Morris) Generic programming with dependent types * Jeremy Gibbons (University of Oxford): Design Patterns as Higher-Order Datatype-Generic Programs * Ralf Hinze (Universitat of Bonn): Generic Programming, Now! (in collaboration with Andres Loeh) * Johan Jeuring (Universiteit Utrecht): Comparing Approaches to Generic Programming (in collaboration with Ralf Hinze and Andres Loeh) * Ralf Laemmel (Microsoft) The next 700 traversal approaches * Tim Sheard (Portland State University): Putting the Curry-Howard Isomorphism to work. Copies of the draft lecture notes will be provided to all participants. The purpose of the student session is to give students an opportunity to present their work and get feedback. Registrants are invited to propose short talks (15-20 min). The selection will be based on abstracts of 150-400 words. ************ Social programme ************ A conference dinner will be organised (attendance at which will be charged seperately). ************ Organisers ************ Roland Backhouse (University of Nottingham) Jeremy Gibbons (University of Oxford) Ralf Hinze (Universitat Bonn) Johan Jeuring (Universiteit Utrecht) Fermin Reig (University of Nottingham) ************ Co-location ************ The Symposium on Trends in Functional Programming (TFP 2006), and the Conference of the Types Project (TYPES 2006) will be held in Nottingham the week before this spring school. ************ Registration and cost ************ To register, send an email to the following address: gp2006(at)cs.nott.ac.uk A small fee will be charged to cover photocopying of the draft proceedings, coffee, etc. ************ Accommodation ************ Participants are expected to arrange their own accommodation. See the school's web site for information about accommodation in the campus and its vicinity. ************ APPSEM ************ This is an APPSEM affiliated event. APPSEM funds can be used to support participants from APPSEM affiliated sites. ************ Further information ************ Web: http://www.cs.nott.ac.uk/ssdgp2006/ Email: gp2006(at)cs.nott.ac.uk 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

RE: [Haskell] Re: haskell.org Public Domain
by Simon Peyton-Jones 17 Jan '06

17 Jan '06

I'm no expert on licenses, but I'd like to say what I hope we can achieve GOALS A) It should be easy for people to contribute to the Wiki. In particular, it should be easy for multiple people to contribute to a single Wiki page, so that the question "who is the author" has (by design) no clear answer. B) It should be easy to use material taken from the Wiki: i) it should be easy to know what the license is ii) the license should make it easy to use the material To me B(i) suggests that we should avoid a multiplicity of licenses. Having a different license per-page would be bad enough, but the multiple-authorship of a Wiki means that we could end up with different licenses for different bits of the same page. My suggestion would be * One license for the Wiki. If a contributor wants to put up material with a different license, then link to it as Udo suggested. (This also makes it clear that the link is to material that is not to be edited by others, whereas by definition the entire Wiki actively solicits editing by others.) * That license should be maximally permissive. Anything viral defeats B(ii). Preferably even more permissive than BSD (e.g. no obligation to display a copyright notice. Who would the copyright notice be *to*?) I'm not fussy about the details. Just some way of saying "You can do what you like with this material". Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 10 January 2006 22:30 | To: haskell(a)haskell.org | Subject: Re: [Haskell] Re: haskell.org Public Domain | | Am Dienstag, 10. Januar 2006 23:03 schrieb John Meacham: | > [...] | | > I would say something like 'contributions and any derivations must be | > usable for any purpose by anyone in perpetuity without restriction' so | > that public domain, BSD, or the GHC license are all fine. | | First, the GHC license is a BSD-style license as far as I know. Second, | BSD-style licenses have restrictions. The restriction I remember is that | derivative works have to include the original copyright notice, the | disclaimer, etc. | | If we do as you propose, different licenses could be chosen and the "user" | wouldn't know what the exact licensing terms of this or that article are. I | think, it is better to choose one permissive license for all the content. | | > [...] | | > John | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

15 40

HDBC Transactions with Sqlite3
by Tom Hawkins 15 Jan '06

15 Jan '06

I have HDBC running with Sqlite3, but I'm getting a SqlError due to a locked table. Please excuse my SQL ignorance, but what may be causing the problem? In SQL, are we not allowed to select, update, and delete from a table within a single transaction? If not, what are the rules for transactions? Thanks for any help! -Tom SELECT * FROM freeKey; SELECT * FROM nextKey; INSERT INTO nextKey VALUES (1); SELECT * FROM freeKey; SELECT * FROM nextKey; UPDATE nextKey SET key = 2 WHERE key = 1; SELECT * FROM freeKey; SELECT * FROM nextKey; UPDATE nextKey SET key = 3 WHERE key = 2; INSERT INTO freeKey VALUES (0); INSERT INTO freeKey VALUES (1); SELECT * FROM freeKey; DELETE FROM freeKey WHERE key = 0; SqlError {seState = "", seNativeError = 1, seErrorMsg = "step: database table is locked"}

2 1

Looking for a random-access sequence data structure
by Duncan Coutts 14 Jan '06

14 Jan '06

Hi all, I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a -> Int -> Maybe a insert :: Sequence a -> Int -> a -> Sequence a delete :: Sequence a -> Int -> Sequence a Obviously I can implement this with ordinary lists in O(n) time for each operation. It seems that this could be done in O(log n) time for each operation. This seems like a fairly common collection signature to want but to my surprise I've not been able to find any existing implementations that support it. There are several that have almost all the necessary operations. For example the Data.Map supports all of these except insert. Okasaki's random access lists only support inserting elements at the head of the list. I'd guess that some kind of (balanced) binary search tree where each node is annotated with the number of nodes below it could support all these operations. Duncan

6 12

ANN: HDBC (Haskell Database Connectivity)
by John Goerzen 14 Jan '06

14 Jan '06

Hi, I'm pleased to announce the first alpha release (I could call it a "developer's preview", but then I don't wear a suit) of HDBC. HDBC is the Haskell Database Connectivity library. It is patterned after Perl's DBI. I wrote it from scratch -- this is not a reimplementation of HSQL -- because several design decisions in HSQL have been causing me trouble. I am also announcing the first alpha release of the Sqlite3 backend driver for HDBC. I anticipate writing backend drivers for the same databases HSQL supports (though probably not Sqlite2), but it should be easier for others to write HDBC drivers as well. To answer a potential FAQ, HDBC does not attempt to do what HaskellDB does, though HDBC could potentially replace HSQL as the underlying layer of choice in HaskellDB. I'm including the README below, which goes into a bit more detail. To get HDBC: darcs get --partial http://darcs.complete.org/hdbc To get the Sqlite3 driver: darcs get --partial http://darcs.complete.org/hdbc-sqlite3 Welcome to HDBC, Haskell Database Connectivity. HDBC is modeled loosely on Perl's DBI interface, though it has also been influenced by Python's DB-API v2, JDBC in Java, and HSQL in Haskell. Features of HDBC ---------------- HDBC provides an abstraction layer between Haskell programs and SQL relational databases. This lets you write database code once, in Haskell, and have it work with any number of backend SQL databases (MySQL, Oracle, PostgreSQL, ODBC-compliant databases, etc.) HDBC is a from-scratch effort. It is not a reimplementation of HSQL, though its purpose is the same. Some features HDBC has which HSQL lacks include: * Ability to use replacable parameters to let one query be executed multiple times (eliminates the need for an "escape" function) * Ability to access returned rows by column number * Ability to read data from the SQL server on-demand rather than reading the entire result set up front * HUnit testsuite for each backend driver * Well-defined standard API and easy backend driver implementation Features on the TODO list which will appear shortly include: * Support for translation between Haskell and SQL types * Lazy reading of the entire result set (think hGetContents, but for the results of SELECT) * Support for querying metadata (column names, types, etc.) * Additional infrastructure for querying database server properties * Add-on package to integrate with MissingH (filesystem in a database, backend for AnyDBM, etc.) HDBC Drivers ------------ The following HDBC drivers exist: Sqlite v3, darcs get --partial http://darcs.complete.org/hdbc-sqlite3 More will be coming shortly. -- John Goerzen December 20, 2005

8 19

New look for haskell.org: MediaWiki
by John Peterson 11 Jan '06

11 Jan '06

As everyone has noticed during the "making Haskell more open" discussion, MediaWiki was suggested as a better wiki technology for haskell.org. Ashley Yakeley has generously installed MediaWiki and we would like to migrate the main pages of haskell.org into this wiki. The migration is not complete - only the front page is finished - but I'd like to make this public now so that there's time for comments. In the end, this will allow anyone to come in and fix up the main haskell.org pages - the people, the projects, the help for beginners, whatever you want. Olaf and I will then step back and let the community work directly on the entire site without having to bother us (a big advantage!). This will also impact the old Haskell wiki. Rather than try to automatically convert the old wiki to the new one, we're going to ask the community to come in and do this for us. In particular, the new wiki is under the GNU FDL so the licenses are not necessarily compatible. We will keep the two wikis going "side by side" for a while but in the long term I hope all content migrates to MediaWiki (we won't be deprecating the Trac stuff - this will stay as is). I believe that MediaWiki is more professional looking and has a nice separation of documentation and discussion that MoinMoin lacks. I hope that this will result in better wiki content and a more organized site. Moving content by hand will give us all a chance to spruce up the existing content as it moves (and get rid of all the ugly CamelCase page names!). I expect that it will take another week or so for the rest of the haskell.org pages to move into the new wiki - at that point we'll "flip the switch" and take down the old pages (but not the old wiki yet) and change the main page to point into the MediaWiki. Content that isn't being maintained by Olaf and I will stay as before although I hope that more and more pages will move into the wiki and we won't have to give out accounts to people on haskell.org just to host projects. The new wiki isn't yet visible from the front page but you can find it at http://haskell.org/haskellwiki/Haskell For you style sheet gurus, the style sheet itself is also in the wiki at http://haskell.org/haskellwiki/MediaWiki:Quiet.css If anyone wants to help move the main pages over, drop me an email and I'll coordinate things. Feel free to start adding stuff to the new wiki. It won't be visible to the outside world immediately but you can get it ready for the switch over. This isn't a completely "done deal" - there is still time to object to the whole thing or make suggestions. Nothing will be visible to the outside world until we make the switch later. But I believe this will result in a much better site and also make life a lot easier for Olaf and I. (And I apologize to everyone that's asked for updates to haskell.org recently - I've been avoiding them to concentrate on this!). I'm sure some of the MediaWiki settings still need to be tweaked. Send me mail if something in the configuration of MediaWiki needs to be changed. A big thanks again to Ashley! John

22 41

MonadPlus vs. Monoid
by Twan van Laarhoven 10 Jan '06

10 Jan '06

I was wondering, in the MonadPlus documentation it says that: * mzero is the identity of mplus (and some extra conditions) * mplus is an associative operation While for Monoid we have: * mempty is identity of mappend * mappend is an associative operation MonadPlus is of course a 'stronger' assertion. But why is not every instance of MonadPlus also an instance of Monoid? > instance MonadPlus m => Monoid (m a) where > mempty = mzero > mappend = mplus The only type that is an instance of both is [a]. But I see no reason why it there should not be a Monoid instance for other MonadPlus types. In particular, an instance for Maybe could be useful with a writer monad when you are only interested in the first result. Twan

3 2

Re: [Haskell] GHC and GLUT
by Wolfgang Jeltsch 10 Jan '06

10 Jan '06

Am Montag, 9. Januar 2006 10:56 schrieb Axel Simon: > On Fri, 2006-01-06 at 22:37 +0100, Wolfgang Jeltsch wrote: > > Hello again, > > > > now that I had installed libsm-dev and libxmu-dev, building a Gears > > binary worked well. Since the problem didn't seem related to the GHC > > version, I deinstalled the GHC backports and installed GHC from sarge > > again which is 6.2.2. > > > > However, with GHC 6.2.2 I got these error messages during compiling > > Gears.hs: > > > > /tmp/ghc10821.hc: In function `sfcm_ret': > > /tmp/ghc10821.hc:1098: warning: assignment discards qualifiers from > > pointer target type > > /tmp/ghc10821.hc: In function `sfcf_ret': > > /tmp/ghc10821.hc:1216: warning: assignment discards qualifiers from > > pointer target type > > /tmp/ghc10821.hc: In function `sfc8_ret': > > /tmp/ghc10821.hc:1334: warning: assignment discards qualifiers from > > pointer target type > > /tmp/ghc10821.hc: In function `Main_info_entry': > > /tmp/ghc10821.hc:1443: warning: assignment discards qualifiers from > > pointer target type > > > > What does this have to say? > > You probably already got an answer. It's to do with const modifiers that > ghc cannot produce correctly since FFI declarations do not take const > modifiers. There was a discussion about this, but all solutions were too > intrusive with respect to the net gain (removing some warnings). So the warnings are harmless? But why don't they occur with GHC 6.4? > Axel. Best wishes, Wolfgang

1 0

Haskell Performance Resource
by Simon Marlow 10 Jan '06

10 Jan '06

There has been a lot of talk about Haskell performance recently, particularly in relation to the shootout benchmarks, with many useful techniques being mentioned. Some of this information is already available in various bits of documentation, and some of it is only emitted in small nuggets by people like me when they are prodded in the right places (sorry :-). So I felt motivated to start organising some pages on the wiki where we can collect performance-related wisdom. Here it is: http://haskell.org/haskellwiki/Haskell_Performance_Resource The content is quite thin right now, but I hope others will start adding stuff (and by all means fiddle with the structure too - nothing's set in stone). I've added some material from GHC's user guide, and I plan to move the rest of the performance-related material from there in due course. Cheers, Simon

1 0

Re: ANN: HDBC (Haskell Database Connectivity)
by oleg＠pobox.com 10 Jan '06

10 Jan '06

Axel Simon wrote, in response to Keean Schupke > > dbConnectWith :: DbName -> (DbHandle -> IO Result) -> Result > > dbConnectWith name workFn = do > > handle <- dbConnectTo name > > workFn handle `finally` dbDisconnect handle > > > > In this way you avoid finalizers... and everthing is safe providing you > > only export the "with" style functions from the library... Here's an > > example from the library, the connect function: > > I suppose you meant to write "result" rather than "Result". This style > of functions is only safe if the user ensures that DbHandle is never > returned as part of the result. You should have that in your > documentation. It seems using types to enforce the policy that a data base handle cannot ever `leak' out might be a better idea, in Haskell. It is quite straight-forward to do so: cf. the design of the ST monad guarantees that an STRef cannot `leak' out in the result of runST. Monadic Regions (implemented in Haskell) generalize the idea to multiple nested regions: a pointer (or any other resource, e.g., a database cursor) allocated in one region can be used in nested regions but cannot leak outside of the region that created it (Or, to be more precise, cannot be used outside -- and so, can be safely deallocated when the region is exited). Incidentally, the difficulty with finalizers was precisely the argument for using enumerators rather than cursors in database APIs. Takusen has implemented that idea; takusen currently supports Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test shows that takusen can retrieve 2 million rows from a table without running out of memory.

2 1