- Haskell - Haskell.org

ANNOUNCE: Fun in the Afternoon II
by Graham Hutton 14 Feb '07

14 Feb '07

Dear all, *** FUN IN THE AFTERNOON, WED 21 FEB, NOTTINGHAM *** The second Fun in the Afternoon will take place in Nottingham next week, on the afternoon of Wednesday 21st February. This time around, James McKinna will be giving an invited talk to start the event off, and we'll then have three half-hour talks by Jeremy Gibbons, Nils Anders Danielsson, and Lennart Augustsson. We hope it will be as much fun as the first event in Oxford, but for this to be the case we need as many people as possible to come along and join in. Please spread the word! Background ---------- Fun in the Afternoon is a termly seminar on functional programming and related topics. The inaugural meeting was held in Oxford in November last year, and was a great success, with four excellent talks and a large number of participants from across the UK and further afield. For more info, and to join the mailing list: http://sneezy.cs.nott.ac.uk/fun Location -------- The second Fun in the Afternoon will be held on the Jubilee Campus of the University of Nottingham on Wednesday 21st February 2007. Nottingham is centrally located in the UK, and is easily reachable by all forms of transport. Travel info and maps are available from: http://www.nottingham.ac.uk/cs/general/school_directions.php Before the talks start at 2pm, you are welcome to bring your own sandwiches and have lunch with us in the Atrium of the Computer Science building (labelled 4 on the campus map available above). There are two places to buy sandwiches on the campus, either from the cafe on the top floor of the New Business School (labelled 7 on the campus map), or from The Exchange (labelled 2.) The talks will take place in seminar room A32 of the Education (not Computer Science) building on the Jubilee Campus, which is the building labelled 6 on the map. We will put up some signs on the day to help make sure no-one gets lost. We'll retire afterwards to a local pub for further discussion and heated debate, and then to dinner for those interested. Schedule -------- 12.00 - 14.00 : Lunch (bring your own) 14.00 - 15.00 : Matching Regular Expressions, Revisited, Revisited James McKinna, University of St Andrews 15.00 - 15.30 : Coffee 15.30 - 16.00 : Generic and Indexed Programming Jeremy Gibbons, University of Oxford 16.00 - 16.30 : A Well-Typed Interpreter for a Dependently Typed Language Nils Anders Danielsson, Chalmers University of Technology 16.30 - 17.00 : Lennart Augustsson, Credit Suisse Title to be announced 17.00 - 19.00 : Pub 19.00 - : Dinner Titles and abstracts -------------------- Matching Regular Expressions, Revisited, Revisited James McKinna, University of St Andrews We revisit regular expression matching, following Harper's 1999 JFP treatment, recently revisited by Yi, in the context of dependently-typed functional programming. The correctness of matching is delegated to the (self-evident) correctness of the rendering function, to which the recogniser provides an inverse. The use of dependent types to organise the development permits us to develop, in a uniform setting, the intricate mix of operations on regular languages on the one hand, and on the other, their algebraic theory, together with the constructions which relate the two. Generic and Indexed Programming Jeremy Gibbons, University of Oxford The Generic and Indexed Programming project at Oxford started in November 2006, and is funded by EPSRC for three and a half years. The "generic" bit is about programs parametrized by datatypes, and builds on our work on the Datatype-Generic Programming project. This talk is about the "indexed" bit, which concerns lightweight techniques for dependently-typed programming, for example using generalized algebraic datatypes. Specifically, values are reflected at the type level, and can then be used as "phantom type" indices to other types, expressing certain kinds of constraints; the relationship between type representations and values, important in datatype-generic programming, is one application. We will explain our motivation, show some cool examples, and say a little about where we see the project going. A Well-Typed Interpreter for a Dependently Typed Language Nils Anders Danielsson, Chalmers University of Technology GADTs are often introduced with the "well-typed interpreter" example. A simple programming language is encoded as a GADT in such a way that only well-typed terms can be defined, and then an interpreter which cannot get stuck is implemented. I'll show how to do this for a dependently typed lambda calculus, in the dependently typed meta-language AgdaLight. To accomplish this I'll use inductive-recursive families, a generalisation of GADTs. Lennart Augustsson, Credit Suisse Title/abstract to be announced We look forward to seeing you in Nottingham next week! If you are planning to come, it would be useful if you can drop us a line and also say if you are likely to come for dinner, in order that we can estimate numbers for coffee and dinner. Best wishes, Graham and Conor +---------------------------------------------------------------------+ | Dr Graham Hutton Email : gmh(a)cs.nott.ac.uk | | School of Computer Science and IT | | University of Nottingham Web : www.cs.nott.ac.uk/~gmh | | Jubilee Campus, Wollaton Road | | Nottingham NG8 1BB, UK Phone : +44 (0)115 951 4220 | +---------------------------------------------------------------------+ 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

ANNOUNCE: Haskell Xcode Plugin (version feb0707)
by Lyndon Tremblay 14 Feb '07

14 Feb '07

Announcement of the first release of a plugin for Xcode enabling syntax highlighting, Xcode projects compiling and linking, and a couple missing features, for Haskell (GHC). http://www.hoovy.org/HaskellXcodePlugin/ Instructions, features, and screenshots are available on this page. Enjoy, until next release! -lyndon

2 1

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

13 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 12 Feb '07

12 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 12 Feb '07

12 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 12 Feb '07

12 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