February 2007 - Haskell

ANN: Vty 3.0.0
by Stefan O'Rear 14 Feb '07

14 Feb '07

Yet another new major of vty has been produced. While I had hoped this compatibility break would never be needed, it seems vty 2's lazy lists and unpacked records were preventing good performance, so the level of abstraction has been increased by creating opaque types Image and Attr. Internally, the new Image uses side effectful array update (unsafePerformIO is not needed because it can only be read by the IO-using update procedure), and the new Attr uses bit flags packed into a single Word#. Yi, using the new release, has doubled in speed with no additional tuning. There are no other notable API changes. (although internally a Cursor-level control module has been factored out, perhaps in preparation for being exposed) As always, feedback is appreciated. Stefan Tar: http://members.cox.net/stefanor/vty/dist/vty-3.0.0.tar.gz Haddock: http://members.cox.net/stefanor/vty/dist/doc/html/index.html Darcs: darcs get --tag=rel-3.0.0 http://members.cox.net/stefanor/vty/

1 0

ANNOUNCE: TV-0.2 and GuiTV-0.2
by Conal Elliott 13 Feb '07

13 Feb '07

*TV* <http://haskell.org/haskellwiki/TV> is a library for composing *tangible values* ("TVs"), i.e., values that carry along external interfaces. In particular, TVs can be composed to create new TVs, *and* they can be directly executed with various kinds of interfaces. Values and interfaces are *combined* for direct use, and *separable* for composition. GuiTV <http://haskell.org/haskellwiki/GuiTV> adds graphical user interfaces to the TV <http://haskell.org/haskellwiki/TV> (tangible value) framework, using Phooey <http://haskell.org/haskellwiki/Phooey>. The functionality was part of TV <http://haskell.org/haskellwiki/TV> up to version 0.1.1. I moved it out to a new package to eliminate the dependency of core TV on Phooey and hence on wxHaskell, as the latter can be difficult to install. See this blog post<http://conal-elliott.blogspot.com/2007/02/separating-io-from-logic-example.…>about for an example of using TV to neatly separate logic from IO. - Conal

1 1

Problem compiling happy 1.15
by Rob Hoelz 13 Feb '07

13 Feb '07

I downloaded the source for happy 1.15, and when I run make, this pops up: /usr/bin/ghc -H16m -O -cpp -fglasgow-exts -O -c LALR.lhs -o LALR.o -ohi LALR.hi LALR.lhs:626:34: Not in scope: `bounds' make[3]: *** [LALR.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/rob/downloads/happy-1.15/happy' make: *** [/home/rob/downloads/happy-1.15/happy/src/happy-inplace] Error 2 After erasing hiding (bounds) in these lines: import Data.Array hiding (bounds) import Array hiding (bounds) it does some more work, then this error pops up: /usr/bin/ghc -H16m -O -cpp -fglasgow-exts -O -c ProduceCode.lhs -o ProduceCode.o -ohi ProduceCode.hi ProduceCode.lhs:31:20: Not in scope: `Data.Array.MArray.indices' make[3]: *** [ProduceCode.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/rob/downloads/happy-1.15/happy' make: *** [/home/rob/downloads/happy-1.15/happy/src/happy-inplace] Error 2 Is my configuration messed up or something? Thanks, Rob Hoelz

2 1

class instance lost during re-export & packaging
by Conal Elliott 13 Feb '07

13 Feb '07

I have a package P that contains a class instance specified in one module P.M and re-exported in packaging module P (one that gathers & re-exports for the whole P package). When I import the package module P in a test module, Under ghc-6.6, my instance is not found. If the test module also says "import P.M()", the instance is found. Oddly, I only have this problem with classes defined in a package other than P. In ghci, after loading the module successfully, if I comment out the "import P.M()" and re-load, the instance is found. Is this behavior known, and perhaps even intended? Is there anything I can do to make sure my instance gets packaged up with module P? Thanks, - Conal

2 1

The Monad.Reader - Call for copy
by Wouter Swierstra 13 Feb '07

13 Feb '07

Call for Copy The Monad.Reader - Issue 7 I would like to welcome articles for the next issue of The Monad.Reader. * The Monad.Reader * There are a large number of conferences and journals that accept research papers related to Haskell; unfortunately, the platform for non-academic publications is far less developed. This is where The Monad.Reader fits in. I would like to explicitly encourage people to also submit shorter articles. There is no restriction on the the number of pages. I am always happy to accept good articles: it doesn't matter if they're two pages or twenty. * Submission Details * Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue by e-mail (wss at cs.nott.ac.uk) to me before **April 13th, 2007** . Articles should be written according to the guidelines available from http://www.haskell.org/haskellwiki/TheMonadReader Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll sort something out. Looking forward to your submission, Wouter 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

Checking out the whole source tree
by Rob Hoelz 13 Feb '07

13 Feb '07

I recently checked out the X11 package from darcs.haskell.org, and I'd like to check out more of the source from the darcs repository. I'm still unfamiliar with darcs; how do I check out the whole source tree? Thanks, Rob Hoelz

3 2

The meaning of #{}
by Rob Hoelz 13 Feb '07

13 Feb '07

I've been pouring over the Xlib bindings for Haskell, and I've come across the following code: peekXButtonEvent p = do root <- #{peek XButtonEvent,root} p subwindow <- #{peek XButtonEvent,subwindow} p time <- #{peek XButtonEvent,time} p x <- #{peek XButtonEvent,x} p y <- #{peek XButtonEvent,y} p x_root <- #{peek XButtonEvent,x_root} p y_root <- #{peek XButtonEvent,y_root} p state <- #{peek XButtonEvent,state} p button <- #{peek XButtonEvent,button} p same_screen <- #{peek XButtonEvent,same_screen} p return (root, subwindow, time, x, y, x_root, y_root, state, button, same_screen) I can't seem to find a definition or an explanation for #{}. Is this some kind of operator for dealing with monads or something? Thanks, Rob Hoelz

3 2

Announce: Bytecode Verification for Haskell
by Robert Dockins 13 Feb '07

13 Feb '07

Fellow Haskellers, I am very pleased to announce that I recently completed the degree requirements for my master's. As a part of those requirements, I undertook research that may be of interest to those of you subscribed to this list. My research involved designing and implementing a type verification algorithm for Yhc Haskell bytecode. The final report detailing this research may found at the Tufts CS Department technical reports page [1]. The abstract for the report follows this message. In addition to the report, I have made available the source code for my proof-of-concept implementation, which consists of a simple bytecode compiler and verifier. The source code may be found at the project page for this research [2]. If you have questions or comments please either email me directly or take discussion to the haskell-cafe or yhc mailing lists. Thanks, Rob Dockins [1] http://www.cs.tufts.edu/tr/techreps/TR-2007-2 [2] http://www.eecs.tufts.edu/~rdocki01/masters.html Abstract: In this paper we present a method for verifying Yhc bytecode, an intermediate form of Haskell suitable for mobile code applications. We examine the issues involved with verifying Yhc bytecode programs and we present a proof-of-concept bytecode compiler and verifier. Verification is a static analysis which ensures that a bytecode program is type-safe. The ability to check type-safety is important for mobile code situations where untrusted code may be executed. Type-safety subsumes the critical memory-safety property and excludes important classes of exploitable bugs, such as buffer overflows. Haskell's rich type system also allows programmers to build effective, static security policies and enforce them using the type checker. Verification allows us to be confident the constraints of our security policy are enforced.

1 0

ANNOUNCE: urlcheck 0.1, (smp) parallel link checker
by dons＠cse.unsw.edu.au 13 Feb '07

13 Feb '07

This little tool has been kicking around on my harddrive for a month or two now, so time to release! I'm pleased to announce the first release of urlcheck, an parallel link checker, written in Haskell. Frustrated with the resources and time consumed by 'linkchecker', when preparing the weekly news, I coded up a lightweight, smp-capable replacement in Haskell. urlcheck pings urls found in the input file, checking they aren't 404s. It uses Haskell threads to run queries concurrently, and can transparently utilise multiple cores if you have them. Usage: $ urlcheck urlcheck.html Found 0 broken links. Checked 10 links (10 unique) in 1 file. Search time: 5 secs Get it from Hackage! http://hackage.haskell.org/cgi-bin/hackage-scripts/package/urlcheck-0.1 -- Don

1 0

Positions at Oxford: refactoring tools
by Oege.de.Moor＠comlab.ox.ac.uk 12 Feb '07

12 Feb '07

Programming Tools Group University of Oxford, UK http://progtools.comlab.ox.ac.uk http://aspectbench.org >> fully funded 3-year PhD studentship << >> numerous paid 2-months internships << Applications from researchers in functional programming (or their students) would be particularly welcome! 1. PROJECT SUMMARY: ASPECT REFACTORING TOOLS Software systems are rarely written from scratch: they evolve over long periods of time. When a change is made, this often affects many different locations in a system, and it is hard to make a change consistently. For that reason, automated tools to help the process of software change are desirable. "Refactoring" refers to the process of restructuring an existing piece of software, often prior to introducing new functionality, or to take advantage of a new technology. Refactoring must preserve the behaviour of existing code, and tools that help in refactoring both assist in the restructuring process and in checking that the behaviour has not changed. Unfortunately today's refactoring tools are very hard to construct, they are still quite limited in functionality, and they often contain bugs. This project aims to construct a framework for better refactoring tools. In particular, the work is driven by refactorings for a new set of language features, called `aspect-oriented programming' that have recently been added to Java. Our framework will be based on developments in three separate areas of computer science: * `strategies' to control the process of rewriting program code, from the `term rewriting' community * `reference attributed grammars' to specify the conditions that guarantee behaviour is preserved, from the `compilers' community * `incremental evaluation' of declarative rules, from the `functional and logic programming' community. The quality of our framework will be assessed by coding selected case studies using alternative methods. In particular, we shall implement several refactorings directly in Eclipse, the leading development environment for writing aspect-oriented programs in industry. The project is funded by the EPSRC (UK equivalent of NSF). 2. REQUIREMENTS The PhD student will be concerned with the theoretical foundations of the refactoring framework, for instance proofs of correctness for refactorings, and also for the incremental evaluation mechanism. We are thus looking for someone with good mathematical skills, in particular regarding formal properties of type systems and program analyses. Candidates must have an outstanding undergraduate or master's degree in computer science. Funding is provided to pay for university fees at EU level (overseas candidates need supplementary funding), plus subsistence, travel, equipment etc. The 2-months positions are intended to assist with implementation work. We are thus looking for highly skilled Java programmers; familiarity with program analysis, formal type systems and so on will be an advantage. These internships are in fact short-term appointments as research assistants at the University of Oxford, and so the holders will be paid a salary. Interns can be outstanding undergraduate students who wish to gain research experience. 3. HOW TO APPLY The deadline for applications is March 20, 2007. * For the PhD studentship, follow the instructions on http://web.comlab.ox.ac.uk/oucl/prospective/dphil/ Clearly mark your application "Aspect Refactoring Tools project". Also send a full electronic copy of your application to oege(a)comlab.ox.ac.uk, by March 20, 2007. * For the 2-months positions, send a letter explaining your interest in the project, plus a full cv and the names of 3 referees to oege(a)comlab.ox.ac.uk. 4. FURTHER INFORMATION We are happy to discuss any of the above informally with prospective candidates. Just email one or all of the project leaders: Oege de Moor (oege(a)comlab.ox.ac.uk) Torbjorn Ekman (torbjorn(a)comlab.ox.ac.uk) Mathieu Verbaere (matv(a)comlab.ox.ac.uk)

1 0