December 2012 - Haskell

Re: [Haskell] The end of an era, and the dawn of a new one
by Johan Tibell 05 Dec '12

05 Dec '12

On Wed, Dec 5, 2012 at 12:37 PM, David Terei <davidterei(a)gmail.com> wrote: > I have always considered the LLVM code generator my responsibility and > will continue to do so. I don't seem to find the time to make > improvements to it but make sure to keep it bug free and working with > the latest LLVM releases. So if others want are interested in working > on it then there is plenty of room for that but I'll continue to > maintain it and be responsible for it at the least. I will maintain the I/O manager as per usual, probably together with Bryan and Andreas (but I cannot speak for them of course).

1 0

FINAL CFP PLACES'13 -- Deadline for Abstracts Fri 14 Dec, full papers Fri 21 Dec
by Wim Vanderbauwhede 05 Dec '12

05 Dec '12

FINAL CALL FOR PAPERS PLACES'13 Programming Language Approaches to Concurrency and Communication-cEntric Software 23rd March 2013, Rome, Italy (affiliated with ETAPS 2013) http://places13.di.fc.ul.pt/ ** Important Dates ** Abstract (title & abstract): 14th December 2012 Paper Submission (up to 5 pages): 21st December 2012 Paper Notification: 23rd January 2012 Final versions of papers: 4th February 2012 ** Background ** Applications today are built using numerous interacting services; soon off-the-shelf CPUs will host thousands of cores, and sensor networks will be composed from a large number of processing units. Many applications need to make effective use of thousands of computing nodes. At some level of granularity, computation in such systems is inherently concurrent and communication-centred. To exploit and harness the richness of this computing environment, designers and programmers will utilise a rich variety of programming paradigms, depending on the shape of the data and control flow. Plausible candidates for such paradigms include structured imperative concurrent programming, stream-based programming, concurrent functions with asynchronous message passing, higher-order types for events, and the use of types for communications and data structures (such as session types and linear types), to name but a few. Combinations of these abstractions will be used even in a single application, and the runtime environment needs to ensure seamless execution without relying on differences in available resources such as the number of cores. The development of effective programming methodologies for the coming computing paradigm demands exploration and understanding of a wide variety of ideas and techniques. This workshop aims to offer a forum where researchers from different fields exchange new ideas on one of the central challenges for programming in the near future, the development of programming methodologies and infrastructures where concurrency and distribution are the norm rather than a marginal concern. ** Topics of Interest ** Submissions are invited in the general area of foundations of programming languages for concurrency, communication and distribution. Specific topics include: * language design and implementations for communications and/or concurrency, * session types, * concurrent data types, * concurrent objects and actors, * multicore programming, * use of message passing in systems software, * interface languages for communication and distribution, * program analysis, * web services, * novel programming methodologies for sensor networks, * integration of sequential and concurrent programming, * high-level programming abstractions for security concerns in concurrent, distributed programming, * runtime architectures for concurrency, * scalability and/or resource allocations. Papers are welcome which present novel and valuable ideas as well as experiences. ** Submission Guidelines ** Authors should submit a title and an abstract by Wednesday 14th December 2012. Papers of up to *five pages* in length should be submitted in PDF format by Wednesday 21st December 2012 using the EasyChair proceedings template available at: http://www.easychair.org/easychair.zip Abstracts and papers should be submitted using EasyChair: http://www.easychair.org/conferences/?conf=places2013 Preliminary proceedings will be available at the workshop. The post proceeding will be published as an EPTCS volume. Note that, as we accept short papers, extended versions of the accepted works could be also submitted elsewhere. Enquiries can be sent to the PC co-chairs. ** Program Committee ** Alastair Beresford, University of Cambridge, UK Viviana Bono, Universita di Torino, Italy Alastair Donaldson, Imperial College London, UK Dan Ghica, University of Birmingham, UK Joshua Guttman, Worcester Polytechnic Institute, MA, US Thomas Hildebrandt, University of Copenhagen, Denmark Paul Keir, Codeplay Ltd, UK Hans-Wolfgang Loidl, Heriot-Watt University, UK Conor McBride, University of Strathclyde, UK Jeremy Singer, University of Glasgow, UK Sven-Bodo Scholz, Heriot-Watt University, UK Nikhil Swamy, Microsoft Research, US Wim Vanderbauwhede (co-chair), University of Glasgow, UK Hugo Torres Vieira, Universidade de Lisboa, Portugal Nobuko Yoshida (co-chair), Imperial College London, UK ** Organizing Committee ** Alastair Beresford, University of Cambridge, UK Simon Gay, University of Glasgow, UK Alan Mycroft, University of Cambridge, UK Vasco Vasconcelos, University of Lisbon, Portugal Nobuko Yoshida, Imperial College London, UK

1 0

Haskell from Glorious Kingdom
by Henning Thielemann 04 Dec '12

04 Dec '12

Hi Haskellers, since it is Advent time you might like to listen to a song that I programmed and performed with the Haskell Live-Sequencer [1]: http://www.youtube.com/watch?v=O5k0wUh0lj8 and you might want to check the Live-Sequencer, too. The Live-Sequencer allows to compose songs in Haskore style interactively. The most important feature is that you may alter the running program/song and that you can do so together with many people via network. Best, Henning [1] http://www.haskell.org/haskellwiki/Live-Sequencer

2 1

Re: [Haskell] Status of Haskell'?
by Gábor Lehel 01 Dec '12

01 Dec '12

On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <nate(a)so8r.es> wrote: > >> This standardization process amounts to "endorsement of existing >> features" which seems like not a bad process at all. It makes >> the standard descriptive rather than predictive. > > > +1. I agree generally with Gabor's points -- GHC is in the drivers seat. But > at some point we should take a look at all the things GHC has made that did > pay off and that are good and make them official. > > I'd very much like to see that endorsement happen soon, even if it's not > aggressive. Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me. Maybe as some kind of useful in-between point, the GHC folks could figure out which extensions they like enough that they would, modulo all the details getting figured out and specified, be in favor of them going into a new standard, and fold all of them into a new LANGUAGE definition? So then you would write {-# LANGUAGE HaskellNext #-}, or HaskellGHC, or something like that, to enable all of them in one go. That wouldn't require specifying things down to the tiniest details (which is what a standard requires), but only at the granularity of particular extensions, which is what people seem to be looking for. Maybe instead of the GHC people deciding it, there could be some kind of community process (such as a vote). (And yeah, this sounds eerily similar to -fglasgow-exts, which is what we got rid of in favor of LANGUAGE pragmas, but maybe the fact that -fglasgow-exts turned mostly all extensions on indiscriminately, whereas this would be a curated subset, is a significant enough difference to turn it from a bad idea into a good one.) -- Your ship was destroyed in a monadic eruption.

5 6

Re: [Haskell] Status of Haskell'?
by Simon Peyton-Jones 01 Dec '12

01 Dec '12

I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. The question is: who is "the community"? It's fairly clear that the Haskell Prime process itself is languishing. The last message about the development process that I can find is this one from Malcolm Wallace<http://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html>, in January 2011. But please don't blame Malcolm or the committee<http://hackage.haskell.org/trac/haskell-prime/wiki/Committee>. Developing new, well-specified changes to Haskell will only happen if there is a vigorous eco-system of folk who are prepared to devote the love and time to do it. There are plenty of people (myself among them) who would be delighted if there was a series of well-specified updates to the Haskell standard; but it is harder to assemble a group that is willing to move that process forward. Why not? I don't think it's laziness or selfishness; just look at how helpful people are on the mailing list. Rather, I am guessing that it's a subconscious assessment of cost/benefit. The cost is certainly significant, and (unlike a quick email response on Haskell Cafe) takes place over months. The benefit, for an individual, is harder to articulate. GHC defines a de-facto standard, simply by existing, and for many practical purposes that is good enough. However, GHC is (quite consciously) exploring stuff that may or may not ultimately turn out to be a good idea: it's a laboratory, not an every-detail-thought-out product. [Though of course we try hard to be good enough for production use.] So there is real merit in having a group, not too closely coupled to GHC, that picks off the best ideas and embodies them in a language standard. But if for any one individual, GHC is "good enough", then the benefits of a language standard may seem distant and diffuse. I don't have a solution to this particular conundrum. As many of you will remember, the Haskell Prime process<http://hackage.haskell.org/trac/haskell-prime/wiki/Process> was itself developed in response to a sense that making a "big iteration" of the language was so large a task that no one felt able to even begin it. Hence the deliberately more incremental nature of Haskell Prime; but even this lighter-weight process is rather stuck. I'm sure that any solution will involve (as it did in earlier stages) motivated individuals who are willing to take up leadership roles in developing Haskell's language definition. I'm copying this to the main Haskell list, in the hope of attracting volunteers! Simon From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Nate Soares Sent: 27 November 2012 22:44 To: Ben Millwood Cc: haskell-prime(a)haskell.org Prime Subject: Re: Status of Haskell'? > it might be wise to see what GHC decides to do on that front, first, I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood <haskell(a)benmachine.co.uk<mailto:haskell@benmachine.co.uk>> wrote: On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh <igloo(a)earth.li<mailto:igloo@earth.li>> wrote: > [...] adding DeriveDataTypeable > hopefully wouldn't be too controversial [...] This is a little tricky since the Data class itself makes (essential, I think) use of Rank2Types. Typeable ought to be fine, but it might be wise to see what GHC decides to do on that front, first, e.g. whether it's going to autoderive all instances or forbid user instances or anything else similarly bold. _______________________________________________ Haskell-prime mailing list Haskell-prime(a)haskell.org<mailto:Haskell-prime@haskell.org> http://www.haskell.org/mailman/listinfo/haskell-prime

6 5