September 2009 - Haskell-Cafe

ANN: fclabels-0.4.0 - First class accessor labels.
by Sebastiaan Visser 09 Sep '09

09 Sep '09

Hello all, IFCP is a really inspiring place to hang/hack around with your fellow Haskell hackers. So, straight from Edinburgh, I proudly present a new release of fclabels[1,2], your favourite record selector package. This version is joint work with Chris Eidhof and Sjoerd Visscher. This package has been around for a while but has been changed almost entirely now. Naming is different and has a far more consistent usage. This library might look cryptic at first sight, but give it a try it is not that hard. There are more package around that serve the same purpose (like the Lenses package which was uploaded a few days ago), but I'm convinced the simplicity and elegance of fclabels will strike you all. ;-) The package description is included below. Documentation can be found in the package itself or on Hackage. Gr, -- Sebastiaan Visser [1] Hackage: http://hackage.haskell.org/package/fclabels [2] Github: http://github.com/sebastiaanvisser/fclabels/tree/master * package description * First class labels that act as bidirectional records fields. The labels are fully composable and can be used to get, set and modify part of datatypes in a consistent way. The label datatype, conveniently called `:->', is an instance of the `Category' type class meaning it has a proper identity and composition. The library has support for automatically deriving labels from record selectors that start with an underscore. Labels can be used in a pure functional setting or be applied to mutable state in some state monad.

2 2

ANNOUNCE: graphviz-2999.5.0.0
by Ivan Lazar Miljenovic 09 Sep '09

09 Sep '09

I am pleased to announce version 2999.5.0.0 [1] of the graphviz [2] package for Haskell. This is what I like to think of as the "Hey, this is almost getting to be a decent library!" version :p [1] http://hackage.haskell.org/packages/archive/graphviz/2999.5.0.0/graphviz-29… [2] http://hackage.haskell.org/package/graphviz The graphviz package provides bindings to the GraphViz [3] suite of programs by providing the ability to generate and parse GraphViz's Dot [4] language as well as wrappers around the tools themselves. [3] http://www.graphviz.org/ [4] http://www.graphviz.org/doc/info/lang.html This is an almost complete re-write of the previously released version (2999.1.0.2): I do not mean that this version was re-written from scratch, but substantial portions of the library have been improved or replaced. As such, current users of this library will unfortunately have to update their code that uses it. The major changes (becuase there's probably heaps of smaller changes I've forgotten about) are: * Parsing and printing of Dot code was re-written to use the new ParseDot and PrintDot classes rather than the old Parseable class and the Show class. What this means for the end-user is that quotation problems should finally all be resolved (I hope...). In particular, proper quotation of String values is now done automagically: if it is found that the String to be printed requires quoting (because it does not match the format required for non-quoted String values), then quotes within the String are escaped and the entire String is quoted. As part of this, the Data.GraphViz.ParserCombinators module has been moved to Data.GraphViz.Types.Parsing. * Re-write the various Dot* datatypes in Data.GraphViz.Types. Sub-graphs/clusters are now their own entity rather than being part of DotNode and the Node ID type is now a type parameter rather than being just Int. Sub-graphs/clusters can now also be parsed. DotGraph and DotSubGraph now both contain a "DotStatements" value, which in turn contains global attributes, subgraphs, nodes and edges. * The various conversion functions in Data.GraphViz now come in two flavours: the unprimed versions take in a Bool indicating if the graph is directed or not; the primed versions attempt to automatically detect this. Also add cluster support for the graph -> dot -> graph conversion-style functions, as requested by Nikolas Mayr. * Allow custom arrow types as supported by GraphViz; as requested by Han Joosten. * Fixed a bug in HSV-style Color values where Int was used instead of Double; spotted by Michael deLorimier. * Properly resolved the situation initially spotted by Neil Brown: Matthew Sackman was following Dot terminology for an edge `a -> b' when using "head" for `b' and "tail" for `a' (this is presumably because the head/tail of the arrow are at those nodes). DotEdge now uses "from" and "to" avoid ambiguity; the various Attribute values still follow upstream usage. This should hopefully be the last update that is such an intrusive change. The next release will most likely contain updates on how to specify a particular output to use (including variants), with most of the rest remain as-is. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Takusen: *** Exception: readUTF8Char: illegal UTF-8 character 252
by Günther Schmidt 09 Sep '09

09 Sep '09

Hi all, I'm trying to use Takusen ODBC on Windows. I'm using a German WinXP Pro and try to connect to an MS Access database. As soon as I try to do some inserts the above mentioned exception shows up. Does anyone know a work around for this? Günther

2 1

HList and Type signatures / synonyms
by Günther Schmidt 09 Sep '09

09 Sep '09

Hi, I keep accumulating values and right now use plain tuples for that. I end up with a 12 element tuple and things are a bit messy. I'd like to use extensible Records from HList instead, thing is I'd like to keep putting type signatures in my code. As it turns out that seems to be where it gets messy with HList. Is there a simple way to do this? Günther PS: Does anyone know why there are Label-n modules in HList, and which one to use?

5 5

ANNOUNCE: uvector-algorithms 0.2
by Dan Doel 08 Sep '09

08 Sep '09

Greetings, It is my pleasure to announce version 0.2 of the uvector-algorithms package. The package so far has implementations of several sorting and selection algorithms for use on the mutable arrays from the uvector library, as well as combinators for applying them to immutable arrays. New developments in this version include: - A simple benchmarking program for testing the performance of the algorithms (it's what I use to measure them, but I only have one computer to run it on, so perhaps other folks might want to see how it works on their machine) - A testing program, written with quick check to verify properties of the algorithms - Several bugs found and fixed due to the above tests and using HPC to verify good program coverage - Combinators for Schwartzian transform - Reworking radix sort to be more amenable to optimization. It's now around twice as fast. - A Radix instance for strict pairs, and a radix sortBy - Merge sort is now slightly faster due to memcpy in uvector :) The library can be found at hackage: http://hackage.haskell.org/package/uvector-algorithms or in its darcs repository: http://code.haskell.org/~dolio/uvector-algorithms/ As always, I can be notified of any issues. Enjoy. -- Dan

1 0

ForeignFunPtr
by Maurício CA 08 Sep '09

08 Sep '09

Hi, We have ForeignPtr. Why isn't there a corresponding ForeignFunPtr? Thanks, Maurício

2 3

Looking for a new HWN editor
by Brent Yorgey 08 Sep '09

08 Sep '09

Executive summary: * I'm looking for someone to take over as HWN editor * It is highly automated and doesn't take as much time as you might think (about 3-4 hours/week on average) * You DON'T need to be a Haskell guru * It is far from a thankless job and is a fun way to provide an appreciated service to the community! Read on for more details! ------------------------------------------------------------------------- Hi all, As you probably know, I've been the editor of the Haskell Weekly News for a little over a year now, and I've decided that it's time for me to move on to other things. So, I'm looking for someone to volunteer to take over as HWN editor. Why might you want to do this? It's true that there is no concrete reward. But judging from the number of comments I have received from people over the past year, the HWN provides a valuable and appreciated service to the Haskell community: there are many who simply don't have time to read the mailing lists, but like to know about new libraries, compiler releases, interesting discussions, and other major goings-on in the community. What does the editorship entail? Thanks to some automated tools developed specifically for the job, it doesn't take as much time as you might think: usually about 4 hours per week; most of that is spent simply reading/skimming various Haskell mailing lists to pick out items for the HWN. The process generally goes like this: * pick out funny quotes from the IRC channel using an automated tool * pick out Haskell-related blog posts using an automated tool * pick out announcements and discussions from the mailing list with an automated tool, writing a short blurb for each (usually this just involves cutting and pasting from the announcement itself, with a bit of editing to make it flow * compile text and HTML versions with an automated tool * post to sequence.complete.org and the mailing list. There are much more detailed instructions written up, and of course I'll be happy to provide detailed help and support for the first few weeks of the new editor's tenure. I should emphasize that the HWN editor does NOT need to be a Haskell guru. In fact, this could be an ideal job for someone who is relatively new to Haskell and the community, but would like to contribute in a tangible way. I also want to emphasize that with the change in editorship, the HWN need not remain exactly the same: if you have exciting ideas about changes to make to the format or content, be my guest! The HWN will be whatever you make of it. So, let me know if you are interested! There won't be any formal interview process; the first person to contact me who wants to do it, gets the job. But of course, if you are not sure and want more information, feel free to email me with questions. -Brent

3 3

Ph.D position, Utrecht University, the Netherlands
by S. Doaitse Swierstra 08 Sep '09

08 Sep '09

Subject: Ph.D position, Utrecht University, the Netherlands =================================================== Vacancy PhD student on Realizing Optimal Sharing in the Functional Language Implementations Utrecht University, The Netherlands. =================================================== Within the Software Technology group of the Information and Computing Sciences department of Utrecht University there is a vacancy for a PhD student to work on the efficient implementation of functional languages. The position is funded by NWO, the Netherlands Organization for Scientific Research. ----------------------------------------------------------------------------------------- Project summary: Lambda-calculus and term rewriting are models of computation lying at the basis of functional programming languages. Both possess syntactic meta-theories based on analyzing rewrite steps. Unfortunately, naive implementations are inefficient, since subterms are frequently copied. To overcome this problem in both theoretical systems and actual implementations, duplicate work is avoided by using graph-based term representations, in which identical subterms can be (but not always are) shared. The question arises whether graph-representations and their reductions that are optimal in a theoretical sense can also be practical from an implementer's point of view. However, so far it is unclear whether nice theoretical ideas combine well with existing implementation methods. The overall-goal of this project is to answer this question in a back-and-forth communication between theoretical concepts and practical realizations. Starting points are the recent work on the optimal Lambdascope implementation based on context sharing, and the Haskell implementation developed at Utrecht University. One of the open problems is whether the Lambdascope framework can be extended to efficiently represent sets of mutually recursive definitions. Another, whether global program analysis can discover where Lambdascope-based approaches solve problems due to insufficient sharing. If both questions can be solved, we want to combine Lambdascope-based implementations with conventional frameworks, and investigate how efficient the resulting implementations become. The unique combination of the theoretical depth from the Logic department and the implementation skills and compiler infrastructure from the Computer Science department make Utrecht University the optimal surroundings for such a project. ----------------------------------------------------------------------------------------- Project leaders are Prof.dr. Doaitse Swierstra and dr. Vincent van Oostrom (principal investigator). The project will be executed in close cooperation between * the Software Technology group (http://www.cs.uu.nl/wiki/Center) of the Information and Computing Sciences department (http://www.cs.uu.nl/ ) * and the Theoretical Philosophy group (http://www.uu.nl/EN/faculties/Humanities/research/researchinstitutes/zeno/r… ) of the Philosophy department (http://www.phil.uu.nl/) and between * the more practically oriented PhD student and * the more theory oriented postdoc. ----------------------------------------------------------------------------------------- Requirements: Master degree in Computer Science, Logic, or equivalent. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of lambda-calculus implementations, Haskell, and compiler construction will be useful. Both theory and software development based on this should appeal to you. Terms of employment: the PhD student should start as soon as possible, but no later than January 1, 2010. The position is for four years (after one year there will be an evaluation), full-time. Gross salary starts with € 2042,-- per month in the first year and increases to € 2612,-- in the fourth year of employment. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 3%. In addition we offer: a pension scheme, partially paid parental leave, facilities for child care, flexible employment conditions in which you may trade salary for vacation days or vice versa. Conditions are based on the Collective Employment Agreement of the Dutch Universities: http://www.vsnu.nl/Workstudy/Universities-as-employers-/Collective-Labour-A… More information: * about the project can be found on http://www.cs.uu.nl/wiki/bin/view/Center/OptimalSharing * about the Software Technology group on http://www.cs.uu.nl/wiki/Center * about the Information and Computing Sciences department on http://www.cs.uu.nl/ * about this vacancy can be obtained from Doaitse Swierstra (doaitse(a)cs.uu.nl , +31 6 4613 6929). Send your application in pdf (or another non-proprietary format) to mailto:SciencePenO@uu.nl with a cc to mailto:doaitse@cs.uu.nl. on or before Sept 31, 2009. Mention vacancy nr 62910. _______________________________________________ St-staff mailing list St-staff(a)cs.uu.nl http://mail.cs.uu.nl/mailman/listinfo/st-staff

1 0

ANNOUNCE: dbmigrations 0.1
by Jonathan Daugherty 08 Sep '09

08 Sep '09

dbmigrations is: A library and program for the creation, management, and installation of schema updates (called migrations) for a relational database. In particular, this package lets the migration author express explicit dependencies between migrations and the management tool automatically installs or reverts migrations accordingly, using transactions for safety. This package is written to support any HDBC-supported database, although at present only PostgreSQL is fully supported. To get started, see the included README and MOO.TXT files and the usage output for the "moo" command. Get it from Hackage: http://hackage.haskell.org/package/dbmigrations Or get the source with darcs: http://repos.codevine.org/dbmigrations/ This package is motivated by the need for a framework-independent, solid tool to manage database schema changes in a clean way without assuming a linear sequence of changes assumed by existing tools. dbmigrations lets you manage a forest of schema changes. Future work will include an hscurses-based tool to visualize and manipulate available migrations and their dependencies and support for other database engines. Please don't hesitate to send patches, feedback, and criticism directly to me at drcygnus AT gmail DOT com. I'd like to say thanks to Josh Hoyt and Jason Dagit for suggesting improvements, providing support, and showing me how beautiful Haskell is. Thanks! Enjoy! -- Jonathan Daugherty

2 1

High memory consumption of "print"
by Peter Robinson 08 Sep '09

08 Sep '09

The following toy program consumes either 25MB or 70MB, depending on whether the line print "done" is a comment or code. (Using only 1 OS thread increases memory consumption to 130MB when the print is active vs 25MB when inactive.) What am I doing wrong? --------------------- module Main where import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.TChan import System.Environment import Control.Applicative main = do n <- read . head <$> getArgs tvar <- newTVarIO 0 tchan <- newTChanIO tids <- sequence [ forkIO (test tchan tvar i) | i <- [1..10^n] ] waitForAll tchan $! length tids where waitForAll _ 0 = return () waitForAll tchan len = do atomically $ readTChan tchan waitForAll tchan (len-1) test :: TChan () -> TVar Int -> Int -> IO () test tchan tvar i = do atomically $ do val <- readTVar tvar if val+1 == i then do writeTVar tvar i writeTChan tchan () else retry print "done" --------------------- ghc --make -O2 teststm.hs -threaded && ./teststm 4 +RTS -sstderr

1 0