- Haskell - Haskell.org

ANNOUNCE: xmonad 0.4
by Don Stewart 18 Oct '07

18 Oct '07

The xmonad dev team is pleased to announce the 0.4 release of xmonad! http://xmonad.org xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is written, configured and extensible in Haskell. Custom layout algorithms, key bindings and other extensions may be written by the user in Haskell, in config files. Window layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled across several physical screens. Features: * Simple, intuitive user interface * Stable, fast and small memory footprint * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating windows * XRandR support to rotate, add or remove monitors dynamically * Per-workspace layout algorithms * Per-screens custom status bars * Easy, powerful customisation and reconfiguration * Large extension library * Extensive documentation and support for hacking This is a big release, with every feature we originally proposed for xmonad implemented. Since xmonad 0.3, the following notable improvments have appeared: * Powerful "rules" system: config files may specify rules about how particular applications are handled. For example, gimp might always be placed in the floating layer, or firefox always placed on workspace 2. Gnome dock apps (such as kicker or gnome-panel) might always be placed in a status bar gap and unmanaged. * User-specified workspace tag types (not restricted to numeric keys). E.g. "web" or "www" are valid workspace tags now. * Layouts algorithms serialisable. Current workspace state preserved across restarts/reconfiguration, including user-written modules' state * User written code sandboxed from the core applicuation further, making it safer to experiment with new extensions * 100% code coverage of logic core of xmonad by its testsuite, thanks to QuickCheck and HPC. * More hooks to make writing expressive extensions easier * mod-m to shift focus to the `master' window * many new binary distributions, for various flavours of Linux and BSD, OSX is also well supported. * extensions: xmonad comes with a huge library of extensions (3 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions, see the webpage. Get it! More information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.4 release, and its dependencies, are available from hackage.haskell.org, here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad Brought to you by the xmonad team: Spencer Janssen Don Stewart Jason Creighton Andrea Rossato David Roundy with code contributions from: Brandon Allbery Chris Mears Shachaf Ben-Kiki Eric Mertens Alec Berryman Neil Mitchell Gwern Branwen Devin Mullins Joachim Breitner Daniel Neri Alexandre Buisse Stefan O'Rear Nick Burlett Simon Peyton Jones Peter De Wachter Hans Philipp Annen Aaron Denney Karsten Schoelzel Nelson Elhage Michael Sloan Shae Erisson Ivan Tarasov Joachim Fasting Alex Tarkovsky Michael Fellinger Christian Thiemann David Glasser Joe Thornber Kai Grossjohann Matsuyama Tomohiro Dave Harrison Daniel Wagner Juraj Hercek Ferenc Wagner Sam Hughes Jamie Webb Miikka Koskinen Brent Yorgey David Lazar nornagon Lucas Mai timthelion Robert Marlow Klaus Weidner As well as the support of a cast of hundreds on the #xmonad and #haskell IRC channels, and the wider Haskell, FP and window manager communities. Thanks to everyone for their support!

1 0

Announce: generating free theorems, online and offline
by Janis Voigtlaender 17 Oct '07

17 Oct '07

A while back I announced a library and tools for generating free theorems from Haskell types: http://www.haskell.org/pipermail/haskell/2006-August/018426.html There is now an improved version with new features. To try it out online, visit: http://linux.tcs.inf.tu-dresden.de/~voigt/ft Highlights are: - support for type classes (e.g., enter "elem" and note the generated respects-restrictions) - three different language subsets to choose from, including one that takes selective strictness into account and thus gives theorems that are valid even in the presence of seq and friends (e.g., enter "filter" and compare the outputs for the three language subsets) - equational as well as inequational free theorems, the latter often coming with less restrictive preconditions, and thus being applicable where equational free theorems are not (e.g., enter "head" and compare the outputs in equational vs. inequational style for the second or third language subset) The source code of the library is available from: http://wwwtcs.inf.tu-dresden.de/~voigt/dist.tar.gz This package additionally contains a shell-like interface to the library, giving more control than the web interface. In particular, using it one can declare one's own algebraic data types, type synonyms, type renamings and type classes, and then generate free theorems for types involving those. Credits for the implementation are due to Sascha Boehme! Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

2 1

Module system question
by Iavor Diatchki 17 Oct '07

17 Oct '07

Hello, I have a question concerning Haskell's module system. Consider the following example which defines three modules A,B, and C: > module A where { data X = X } > module B where { class X a } > module C where { import A; import B; data Y = Y X } The question is: "Is there an ambiguity error in module C?". It seems that the answer depends on how we interpret "ambiguous". In the context of module C, the name X may refer to either the class defined in module B, or the datatype defined in module A. Therefore, we could consider X to be ambiguous, and indeed, this is what happens in GHC 6.6. On the other hand, the name X is used in a context where we are expecting a type constructor and not a class name, and therefore the name X could be unambiguously taken to refer to the datatype X, which is what seems to happen in Hugs. I like the Hugs behavior because it accepts more programs. OTOH, GHC's behavior may be a bit simpler to explain and implement(?). Any thoughts? -Iavor

3 3

IN Doubt...
by Manuel Hernandez 16 Oct '07

16 Oct '07

Dear Haskellers, why this program is not accepted by Hugs? equal a a = True equal a b | not(a==b) = False Best, Manher

2 1

pretty-printing Haskell with automatic parens?
by Conal Elliott 15 Oct '07

15 Oct '07

The haskell-src package contains a pretty-printer for Haskell syntax that requires parentheses to be explicitly placed in the (abstract) syntax representation. I have some code for automatically inserting parentheses where necessary (for use before pretty-printing), but I'm guessing someone else has done so better than I. Does anyone have pointers? I'm glad to share my version as well. Cheers, - Conal

2 1

Fingerprints and hashing
by Simon Peyton-Jones 15 Oct '07

15 Oct '07

Dear Haskellers Here's a challenge. We are all familiar with the idea of an MD5 checksum, which provides a reliable "fingerprint" for a file, usually 128 bits or so. If the file changes, the fingerprint is (almost) certain to do so too. There are lots of techniques: CRC, shar?, MD5, etc. For various applications (including identifying common sub-expressions, and version tracking in GHC), I'd like a Haskell library that supports simple fingerprint operations. Below I give an informal specification of such a library. I can think of any number of implementations, but I'd like one that is (a) robust and (b) efficient. By "robust" I meant that with, say, a 128-bit fingerprint the chance of accidental collision is truly low; a non-robust implementation uses the 128-bit space in a non-uniform way [trivial example: gets stuck on zero]. Any takers? I bet some of you have this already, in some form. Simon The module signature would be something like this: data Fingerprint instance Eq Fingerprint instance Ord Fingerprint initialPrint :: Fingerprint class Fingerprintable t where fingerPrint :: t -> Fingerprint -> FingerPrint instance Fingerprintable Char instance Fingerprintable Int instance Fingerprintable Word32 -- etc The fingerPrint operation here is expressed in the traditional way: an accumulator (say 128 bits) into which one stuffs successive values (e.g. a byte stream). However, very important, I also want a more compositional form: instance Fingerprintable Fingerprint so that I can do something like fp :: Expr -> Fingerprint fp (App e1 e2) = fp e1 `fingerPrint` fp e2 Yes, I could thread the accumulator, thus: fp' :: Expr -> Fingerprint -> Fingerprint fp' (App e1 e2) p = fp' e1 (fp' e2 p) but I can't *always* do that; or even if I can, I may already *have* a fingerprint for e1 in my hand, and it's painful to re-traverse e1. Think of hash-consing. An obvious implementation of "instance Fingerprintable Fingerprint" is to divide one fingerprint into words, and feed it into the other via the Word32 instance. But it's not clear to me whether or not that is robust. (Incidentally, one could define the class thus: class Fingerprintable t where fingerPrint :: t -> FingerPrint plus plusFP :: Fingerprint -> Fingerprint -> Fingerprint But I think it'd be less efficient if that was the only way, because of all those now-compulsory plusFP operations.) I'd like one other thing: to be able to trade cost for accuracy. I'd like a 128-bit fingerprint with essentially zero chance of having two distinct values that map to the same fingerprint; and a one-word fingerprint that was a lot more efficient, but where collisions would be entirely possible (again hash-consing is an example).

9 10

PLAN-X 2008 Deadline approaching
by Peter Thiemann 15 Oct '07

15 Oct '07

Call for Papers and Demos ========================= ****** Abstract deadline: Oct. 17, 2007 ****** Paper deadline: Oct. 22, 2007 PLAN-X 2008 --- Programming Language Techniques for XML ACM SIGPLAN Workshop colocated with POPL 2008 San Francisco, California, USA - 9 January 2008 http://gemo.futurs.inria.fr/events/PLANX2008/ The PLAN-X 2008 workshop is the forum to present and discuss bleeding-edge research at the intersection of programming language and data base technology with an emphasis on tree-shaped data structures and their XML representation. Topics of interest are all aspects of XML processing and querying: theories, methodologies, paradigms, language designs, types, analyses, runtime aspects, implementations, tools, applications. This edition of PLAN-X is particularly interested in blending the XML processing approaches developed by the programming languages and data management communities. Expressive power and high performance are among the common goals that these communities pursue. We encourage the submission of crosscutting contributions that apply techniques from one community to problems from the other. The primary criteria for paper selection are originality, relevance, and timeliness to ensure that we can enjoy reports on ongoing and unfinished work with high potential in the workshop. Submissions =========== We seek submissions in two categories * regular papers (10 pages, 30 minutes presentation) * demo papers (4 pages, 10 minutes plenary presentation + 30 minutes slot for individual discussions shared with other demos) For details see the submission instructions on http://gemo.futurs.inria.fr/events/PLANX2008/?page=subm Important Dates =============== Abstract deadline *** 17 October 2007 Submission deadline *** 22 October 2007 Notification 30 November 2007 Final papers due 14 December 2007 Program Committee ================= Veronique Benzaken Université de Paris-Sud 11, France Alin Deutsch University of California, San Diego, USA Wenfei Fan University of Edinburgh, UK Mary Fernandez ATT Research, USA Haruo Hosoya University of Tokyo, Japan Ralf Lämmel Universität Koblenz, Germany Sebastian Maneth National ICT and UNSW, Sydney, Australia Jim Melton Oracle Corporation, USA Michael Schwartzbach University of Aarhus, Denmark Jérôme Vouillon CNRS, France Ioana Manolescu (general chair) Gemo group, INRIA Futurs, France Peter Thiemann (program chair) University of Freiburg, Germany

1 0

C++ bindings
by Wolfgang Jeltsch 12 Oct '07

12 Oct '07

Hello, what are good approaches for creating Haskell bindings to C++ libraries? The most promising so far seems to create C wrappers around the C++ libraries and then bind to them. Is it feasible to bind directly to C++ using ccall by relying on some standardized C++ ABI? What about H/Direct? Are there any other good ways? Thank you for any hints. Best wishes, Wolfgang

2 1

[Fwd: Re: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming]
by Simon Marlow 12 Oct '07

12 Oct '07

[ posting on behalf of Manuel Hermenegildo <herme(a)fi.upm.es>] Subject: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming DAMP 2008: Workshop on Declarative Aspects of Multicore Programming San Francisco, CA, USA (colocated with POPL 2008) January 9, 2008 SUBMISSION DEADLINE: OCTOBER 26 Parallelism is going mainstream. Many chip manufactures are turning to multicore processor designs rather than scalar-oriented frequency increases as a way to get performance in their desktop, enterprise, and mobile processors. This endeavor is not likely to succeed long term if mainstream applications cannot be parallelized to take advantage of tens and eventually hundreds of hardware threads. Multicore architectures will differ in significant ways from their multisocket predecessors. For example, the communication to compute bandwidth ratio is likely to be higher, which will positively impact performance. More generally, multicore architectures introduce several new dimensions of variability in both performance guarantees and architectural contracts, such as the memory model, that may not stabilize for several generations of product. Programs written in functional or (constraint-)logic programming languages, or even in other languages with a controlled use of side effects, can greatly simplify parallel programming. Such declarative programming allows for a deterministic semantics even when the underlying implementation might be highly non-deterministic. In addition to simplifying programming this can simplify debugging and analyzing correctness. DAMP is a one-day workshop seeking to explore ideas in programming language design that will greatly simplify programming for multicore architectures, and more generally for tightly coupled parallel architectures. The emphasis will be on functional and (constraint-)logic programming, but any programming language ideas that aim to raise the level of abstraction are welcome. DAMP seeks to gather together researchers in declarative approaches to parallel programming and to foster cross fertilization across different approaches. Specific topics include, but are not limited to: * suitability of functional and (constraint-)logic programming languages to multicore applications; * run-time issues such as garbage collection or thread scheduling; * architectural features that may enhance the parallel performance of declarative languages; * type systems and analysis for accurately knowing or limiting dependencies, aliasing, effects, and nonpure features; * ways of specifying or hinting at parallelism; * ways of specifying or hinting at data placement which abstract away from any details of the machine; * compiler techniques, automatic parallelization, automatic granularity control; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs; * design and implementation of domain-specific declarative languages for multi-core; Submission: Submitted papers papers should not exceed 15 pages in LLNCS format. Submission is electronic via: http://www.easychair.org/DAMP2008/ Important dates: Paper submission: Oct 26 Notification to authors: Nov 30 Camera ready: Dec 14 Program Chair: Manuel Hermenegildo Technical University of Madrid / IMDEA-Software -- herme(a)fi.upm.es University of New Mexico -- herme(a)unm.edu Program Committee: Koen De Bosschere (U. of Gent, Belgium) Manuel Carro (Tech. U. of Madrid, Spain) Manuel Chakravarty (U. of New S. Wales, Australia) Clemens Grelck (U. of Luebeck, Germany) Dan Grossman (U. of Washington, USA) Suresh Jagannathan (Purdue U., USA) Pedro Lopez-Garcia (Tech. U. of Madrid, Spain) Lee Naish (Melbourne University, Australia) Leaf Petersen (Intel Corporation, USA) Enrico Pontelli (New Mexico State U., USA) John Reppy (U. of Chicago, USA) Vitor Santos-Costa (U. of Porto, Portugal) General Chairs: Leaf Petersen Neal Glew Intel Corporation Santa Clara, CA, USA leaf.petersen(a)intel.com neal.glew(a)intel.com URL: http://www.cliplab.org/Conferences/DAMP08 Past DAMPs: http://glew.org/damp2006 http://www.cs.cmu.edu/~damp -- -- ------------------------------------------------------------------------------- Manuel Hermenegildo | Prof., C.S. Department Director, IMDEA-Software and CLIP Group | T.U. of Madrid (UPM) http://www.cliplab.org/herme | +34-91-336-7435 (W) -352-4819 (Fax) -------------------------------------------------------------------------------

1 0

Abstract syntax representation
by paolot＠informatik.uni-bremen.de 11 Oct '07

11 Oct '07

Hi, I am writing translations of Haskell to specification languages. I was wondering whether there already exist a representation of Haskell syntax that, in contrast with standard abstract syntax, is "light" on structure (few data-types, few constructors) and has no dictionary parameters. Thanks, -paolo

1 0