- Haskell - Haskell.org

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

AutoForms release 0.2
by Mads Lindstrøm 27 Aug '06

27 Aug '06

Hi all Haskeleers I am pleased to announce AutoForms release 0.2. AutoForms is a library to ease the creation of Graphical User Interfaces (GUI). It does this by using generic programming (SYB) to construct GUI components. See the full description at http://autoforms.sourceforge.net/ . Any comments will be much appreciated. Greetings, Mads Lindstrøm

1 0

Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
by L. J. 27 Aug '06

27 Aug '06

On 8/27/06, John Hughes <rjmh(a)cs.chalmers.se> wrote: > > > > Hi, I use the operation 'readFile' for obtain information locates on > > a file. When I try to write another information on the same file, I > > obtain this error message: "openFile: permision denied". I found this: > > "The readFile operation holds a semi-closed handle on the file until > > the entire contents of the file have been consumed. It follows that an > > attempt to write to a file (using writeFile, for example) that was > > earlier opened by readFile will usually result in failure with > > isAlreadyInUseError." in this web > > http://www.haskell.org/onlinereport/io.html. > > > > How can I break that semi-closed handle for to write in the > > preaviously readed file? Thank you. > > readFile returns an *unevaluated* list of characters from the file--as your > program needs those characters, so they will be read from the file. Once > they have all been read, then the file is closed. So to ensure that the > file is closed, you just have to make sure your program reads all the > characters. One way is to count them. So here's a function that reads a > file, then rewrites it with "hello" added at the beginning: > > addHello f = do > s <- readFile f > length s `seq` writeFile f ("hello"++s) > > length s counts the characters in the file (forcing it all to be read), and > the `seq` is like a semicolon in C: it forces length s to be computed before > the writeFile is performed. > > John Thanks you for your code. I try with it and it works well, but I can not use it in my aplication because I read the file in one function, I compute the results with the readed information and, finally, I wrote this results in another function (in this moment I do not have the readed string, I have my structured data). How can I use this `seq` with different functions?

4 5

Re: [Haskell] [Haskell - I/O] Problem with 'readFile'
by L. J. 27 Aug '06

27 Aug '06

On 8/27/06, Donald Bruce Stewart <dons(a)cse.unsw.edu.au> wrote: > djsenda: > > Hi, I use the operation 'readFile' for obtain information locates on > > a file. When I try to write another information on the same file, I > > obtain this error message: "openFile: permision denied". I found this: > > "The readFile operation holds a semi-closed handle on the file until > > the entire contents of the file have been consumed. It follows that an > > attempt to write to a file (using writeFile, for example) that was > > earlier opened by readFile will usually result in failure with > > isAlreadyInUseError." in this web > > http://www.haskell.org/onlinereport/io.html. > > > > How can I break that semi-closed handle for to write in the > > preaviously readed file? Thank you. > > Due to lazy IO, you'll need to either read the entire file first, before > you can safely write to that file, (or explicitly close the Handle): > > import Control.Exception > > main = do > s <- readFile "x" > evaluate $ length s -- evaluate the list, reading it in > writeFil e "x" (reverse s) GHCi says me that: evaluate is not in scope > Here we use 'evaluate (length s)' to explictily force the entire file to > be read, which will close the Handle, and allows us to safely write back > to the same file. > > -- Don > > P.S. Learning Haskell questions are better addressed to haskell-cafe(a)haskell.org Ok, for another question I will write in this mailing list.

1 0

Re: [Haskell] Exists any null instruction in Haskell?
by L. J. 27 Aug '06

27 Aug '06

On 8/27/06, Neil Mitchell <ndmitchell(a)gmail.com> wrote: > [Moving to haskell-cafe] > > Hi, > > > I want to know if it exists a null instruction (a instruction > > that do anything > > Not really, since instructions don't "do anything" anyway - they only > compute values. > > If you are in the IO monad then "return ()" is the do nothing. I need this answer. This is my case. Thanks you very much. > In the function world, "id" is the do nothing. > > In recursive list processing, then something like [] is probably the > "base case" in a recursive function, so stops the recursivity. > > If you give a more concrete example, then maybe we can give you a better answer. > > Thanks > > Neil >

1 0

[Haskell - I/O] Problem with 'readFile'
by L. J. 26 Aug '06

26 Aug '06

Hi, I use the operation 'readFile' for obtain information locates on a file. When I try to write another information on the same file, I obtain this error message: "openFile: permision denied". I found this: "The readFile operation holds a semi-closed handle on the file until the entire contents of the file have been consumed. It follows that an attempt to write to a file (using writeFile, for example) that was earlier opened by readFile will usually result in failure with isAlreadyInUseError." in this web http://www.haskell.org/onlinereport/io.html. How can I break that semi-closed handle for to write in the preaviously readed file? Thank you.

3 2