August 2006 - Haskell

Announcing Djinn, version 2004-12-11, a coding wizard
by Lennart Augustsson 07 Apr '11

07 Apr '11

Howdy, y'all! I've written a small program that takes a (Haskell) type and gives you back a function of that type if one exists. It's kind of fun, so I thought I'd share it. It's probably best explained with a sample session. calvin% djinn Welcome to Djinn version 2005-12-11. Type :h to get help. # Djinn is interactive if not given any arguments. # Let's see if it can find the identity function. Djinn> f ? a->a f :: a -> a f x1 = x1 # Yes, that was easy. Let's try some tuple munging. Djinn> sel ? ((a,b),(c,d)) -> (b,c) sel :: ((a, b), (c, d)) -> (b, c) sel ((_, v5), (v6, _)) = (v5, v6) # We can ask for the impossible, but then we get what we # deserve. Djinn> cast ? a->b -- cast cannot be realized. # OK, let's be bold and try some functions that are tricky to write: # return, bind, and callCC in the continuation monad Djinn> type C a = (a -> r) -> r Djinn> returnC ? a -> C a returnC :: a -> C a returnC x1 x2 = x2 x1 Djinn> bindC ? C a -> (a -> C b) -> C b bindC :: C a -> (a -> C b) -> C b bindC x1 x2 x3 = x1 (\ c15 -> x2 c15 (\ c17 -> x3 c17)) Djinn> callCC ? ((a -> C b) -> C a) -> C a callCC :: ((a -> C b) -> C a) -> C a callCC x1 x2 = x1 (\ c15 _ -> x2 c15) (\ c11 -> x2 c11) # Well, poor Djinn has a sweaty brow after deducing the code # for callCC so we had better quit. Djinn> :q Bye. To play with Djinn do a darcs get http://darcs.augustsson.net/Darcs/Djinn or get http://darcs.augustsson.net/Darcs/Djinn/Djinn.tar.gz Then just type make. (You need a Haskell 98 implementation and some libraries.) And then start djinn. For the curious, Djinn uses a decision procedure for intuitionistic propositional calculus due to Roy Dyckhoff. It's a variation of Gentzen's LJ system. This means that (in theory) Djinn will always find a function if one exists, and if one doesn't exist Djinn will terminate telling you so. This is the very first version, so expect bugs. :) Share and enjoy. -- Lennart

8 13

Haskell-mode 2.0
by Stefan Monnier 02 Feb '09

02 Feb '09

I have recently taken over maintainership of Haskell-mode, and after making a bunch of changes, I figured it would be a good idea to make a new release. You can find this new release at: http://www-perso.iro.umontreal.ca/~monnier/elisp/ If you think it should also be found at http://www.haskell.org/haskell-mode/, then please tell John Peterson to get back to me (my email to him seem to go straight to the bitbucket. John?). This release has several changes that have all been only lightly tested, especially w.r.t compatibility with various Emacsen. See appended the NEWS file that describes some of the notewirthy changes. Stefan Changes since 1.45: * keybindings C-c <char> have been replaced by C-c C-<char> so as not to collide with minor modes. * The following modules are now automatically activated without having to add anything to haskell-mode-hook: haskell-font-lock (just turn on global-font-lock-mode). haskell-decl-scan (just bind `imenu' to some key). * In recent Emacsen, haskell-doc hooks into eldoc-mode. * haskell-hugs and haskell-ghci are superceded by inf-haskell. * Indentation rules have been improved when using layout inside parens/braces. * Symbols like -> and \ can be displayed as actual arrows and lambdas. See haskell-font-lock-symbols. * Tweaks to the font-lock settings. Among other things paren-matching with things like \(x,y) should work correctly now. * New maintainer <monnier(a)gnu.org>.

3 6

Compilation of big, computed tables
by Stefan Karrmann 24 Oct '06

24 Oct '06

Dear all, can ghc compile huge tables into efficient code if they are constant at compile time? Two examples may clearify the question: big1 :: UArray Int Char big1 = array (0,1000) $! map (\i -> (i,toEnum i)) [0..1000] big2 = sum [0..10000]::Int -- == 50005000 == n*(n+1)/2 where n = 10000 Both values are constant at compile time. As they are given by pure functions, the compiler could evaluate them and write the *result* into the object file 'foo.o'. This would save code size and run time. I peeked into 'foo.hc' but I didn't found 0x2fb0408 nor an array {0, 1, 2, 3, ..., 1000} or similar things. The function in big2 should show that the computation of the value could be very time consuming. If the compiler does not compute it, the source file could be generated by a helper program (or template Haskell?). The function in big1 should show that the conversion of the data into an array could be run-time, code-size and heap-size consuming. (You need the list (maybe explicitly - think of 1000 fixed pseudo-random numbers) and convert it into an array.) If the compiler generates the unboxed array directly it could be rather efficient. PS: I compiled with: ghc6 -c -O2 -keep-tmp-files -keep-hc-files foo.hs Regards, -- Stefan Karrmann

9 12

ANNOUNCE: Haskell XML Toolbox Version 6.0
by Uwe Schmidt 05 Oct '06

05 Oct '06

Haskell XML Toolbox 6.0 I would like to announce a new version of the Haskell XML Toolbox for processing XML. main new features: * works with ghc 6.4.2 * better XPath integration * separate documentation for filter API and arrow API * arrow API slightly simplified More information and download: http://www.fh-wedel.de/~si/HXmlToolbox/index.html Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

4 4

Haskell XML
by Lucius Meredith 01 Sep '06

01 Sep '06

All, Apologies if this question has been beaten to death, but i'm wondering if anyone out there has plans to do a language-level support for XML processing ala OCamlDuce. i would really like to be writing more code in Haskell, but XML is in almost everything i touch and OCamlDuce provides the right level of compiler support for the sorts of applications i'm writing. Best wishes, --greg -- L.G. Meredith Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740

5 5

DAMP 2007: Call for Papers
by Simon Peyton-Jones 31 Aug '06

31 Aug '06

DAMP 2007: Workshop on Declarative Aspects of Multicore Programming Nice, France 16 January 2007 (colocated with POPL 2007) http://www.cs.cmu.edu/~damp 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. Parallelizing programs is a difficult problem. User specification of parallelism is fraught with pitfalls such as race conditions, non-determinism in thread interactions, a lack of debugging methods, and poorly understood performance consequences. Automatic parallelization of existing imperative languages will not meet the challenge due to dependencies and aliasing. 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 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 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 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 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; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs the design and implementation of domain-specific declarative languages for multi-core; We are looking for short papers (3-5) pages. These can be in the form of a position paper, new ideas, initial results, overview of ongoing research, or even a historical perspective. Submissions are due November 3; notification of acceptance will be sent by December 1; final copies will be due January 5. Programm Chair: Professor Guy Blelloch Department of Computer Science Carnegie Mellon University blelloch(a)cs.cmu.edu Programme Committee: Perry Cheng, IBM T. J. Watson Research Center Gopal Gupta, University of Texas at Dallas Kevin Hammond, University of St Andrews Robert Harper, Carnegie Mellon University Surresh Jagannathan, Purdue University Charles Leiserson, Massachuetts Institute of Technology Christian Lengauer, University of Passau Simon Peyton Jones, Microsoft Research General Chair: Neal Glew Intel Corporation Santa Clara, CA, USA neal.glew(a)intel.com

1 0

Announce: FreeTheorems library and tools
by Janis Voigtlaender 31 Aug '06

31 Aug '06

Hello all, Sascha Boehme, a student of mine, has done a project to implement the Reynolds/Wadler algorithm generating theorems from polymorphic types, plus simplifications and postprocessings for such free theorems. The result can be found at: http://haskell.as9x.info To play with the tool online, follow the link http://haskell.as9x.info/ft.html input some valid Haskell type (there are some restrictions, for example no type classes; see the description), and enjoy the result. The types of many standard Haskell functions are predefined, for example you can also simply enter "filter" to generate the respective free theorem. (For a more complicated example, with still quite readable output, try "zip".) Free theorems can be generated in two "models". The "basic model" is the one from the original papers, ignoring the presence of _|_ and fixpoint recursion in Haskell, thus delivering simpler theorems that are only "morally correct" (a slight abuse of this term from the recent POPL paper). The "fix model" takes _|_ and fixpoint recursion into account, delivering more complicated theorems (mainly by including strictness preconditions). The proper treatment of seq being present in Haskell is not yet implemented. Finally, there is also a Shellac-based interpreter-like tool available for download, with slightly more powerful postprocessing facilities. If you have comments, questions, suggestions, please answer on the list or write directly to Sascha (see CC above) or myself. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

The history of Haskell
by Simon Peyton-Jones 31 Aug '06

31 Aug '06

Haskellers, Many of you will know that Paul Hudak, John Hughes, Phil Wadler, and I have been writing a paper about the History of Haskell http://haskell.org/haskellwiki/History_of_Haskell One of the suggestions made last month was that we add a pictorial time-line of the development of Haskell. Bernie Pope and Don Stewart have been kind enough to do just that. Here is the current draft http://www.cs.mu.oz.au/~bjpop/timeline/timeline.4.png Would you like to take a look, and let us know about a) factual errors? b) suggestions for things we might consider adding or omitting? Of course, we can't include everything, so please do not feel slighted by omission! But do feel free to suggest things. A good way to give feedback is to add to the Wiki page: http://haskell.org/haskellwiki/Talk:History_of_Haskell/Timeline Many thanks. Simon

1 0

Optimistic Evaluation?
by Lajos Nagy 31 Aug '06

31 Aug '06

Hi, I remember once reading a paper by SPJ about Optimistic Evaluation that is somewhere between lazy and strict. If I remember correctly, they even implemented it in GHC. Now, it seems that current version of GHC doesn't support optimistic evaluation (not even as an optional feature), so my question is: what happened to OE? Was it that it seemed like a good idea on paper but not in reality? Or was it too costly to maintain? Or it didn't deliver the goods it promised? I'm just curious. Regards, Lajos Nagy

3 2

ANNOUNCE: Haddock/GHC SoC project over
by David Waern 27 Aug '06

27 Aug '06

Hi everyone, Here is a short status report of the "Port Haddock to use GHC" Summer of Code project, which is now over. Part 1), the GHC modifications, are finished and will be included in the GHC head repository as soon we have made sure that they don't cause any significant slowdowns. Part 2), the actual port of Haddock, is able to render the examples/Test.hs file from the original distribution. There are some problems however, most notably a GHC API panic that keep it from rendering docs for many packages. In terms of functionality, the port is at a very experimental stage, and work remains to render the full set of GHC syntax and to support more than just HTML rendering (e.g Hoogle output). To try the code out, grab these repositories: http://darcs.haskell.org/SoC/ghc.haddock http://darcs.haskell.org/SoC/haddock.ghc You have to compile and install ghc.haddock and then use it to compile and install haddock.ghc. If you want to help out, or just have questions, email me or ping me on #haskell. But maybe the best place to discuss would be haskelldoc(a)haskell.org, where everyone can follow. Big thanks to Google, haskell.org and Simon M! /David

1 0